Wouter Vanden Hove

I confirm this patch fixes the problem. Tested with python 2.7.10 and check_manifest 0.25

I agree, but there is another project called python-dotenv, but I always use django-dotenv. both packages import as a dotenv-module, so there is a naming conflict. you cannot use both...

this gives a syntax-warning right now: ``` elif not re.search(r'^\s*(?:#.*)?$', line): # not comment or blank warnings.warn( "Line {0} doesn't match format".format(repr(line)), SyntaxWarning ```

I disagree that TC400 is an antipattern. In some cases you don't need the full traceback. The python-docs only say: "This method should only be called from an exception handler."...

should this ticket be reopened? I would love to see buildout supporting wheels, since this could mean we can use buildout much more in situations where gcc is not available.

I'm solving this by adding this line to the entrypoint-initialization: ``` # Set PYTHONPATH so forking subprocesses don't loose all packages (e.g. ipython-notebook) os.environ['PYTHONPATH'] = ':'.join(sys.path) ```

A lof of django-packages make this diabolical mistake. Diabolical because just pip-installing such a package will actually erase the source-code of another package, and pip will not even complain. When...

see also https://forum.djangoproject.com/t/change-reusable-apps-naming-recommendation/25233

see https://github.com/jpadilla/django-dotenv/issues/50 this module should be renamed to ``django_dotenv``. You can still alias this for your own backwards compatibility ``` >>> import django_dotenv as dotenv ```

> I'm going to close this as ultimately I think there is nothing to be done here. For future reference, as poetry gains adoption, this will not age well. We...