Deprecate --egg

I would like to deprecate and ultimately remove the --egg option. This will be a backwards incompatible change. This option was originally added in order to work around an issue with namespace packages (#3).

However using this option subtly breaks a number of things, namely:

• Installation from Wheels.
  • This will be a much bigger deal if we move to always installing from Wheel in the future.
• Loss of Control over dependency resolution/satisfaction.
  • If this option is selected than all of it’s dependencies will be installed using setuptools instead of pip.
  • Thus, --index-url, --no-index, --find-links, --cert, and --no-deps flags will not have any affect.
  • PEP440 versioning and --pre support will not have any affect.
  • External/Internal and Verifiable/Unverifiable links protection will no longer have affect, thus reverting things back to the old rules.

Most of this are fundamental problems with attempting to use --egg since the only way to actually get an egg is to pass control back to setuptools and re-enable it’s own built in support for these things. A few of them might possibly be able to be worked around but ultimately I think this option is a footgun we provide to our users.

So given all of the above, I want to deprecate this in 1.6 for removal in 1.8.

[jaraco]

install supposed to be a wrapper to easy_install

I’m not sure that’s true. My understanding is install is a wrapper for the distutils command of the same name, adding support for resolving dependencies (among other things). The easy_install command is meant to be more like an installer (similar to what pip does). It doesn’t derive from the distutils install command. It doesn’t install the current project, but instead installs the packages indicated on the command-line.

I think part of the problem here is there’s an underlying philosophical difference between what pip wants to do and what the users expect.

What pip does:

• Insist on coping all files of a package into a single directory, removing namespace support.

What users expect:

• Some files of a package should be located separately in some cases so they can be edited in place (editable) or so they can be included/excluded at run-time (multi-version).

Setuptools has gone to great pains to maintain that expectation. Prior to PEP420, setuptools was the only package that implements support of editable packages in a namespace packages environment. I personally contributed to the PEP420 implementation because I feel passionately about this feature.

Even with the work around I’ve seen very few successful uses of namespace packages, sooner or later they always seem to bite someone in the ass.

Namespace packages are a very powerful idea. They’re a natural progression of package management. Just like DNS went from a flat namespace to a nested one and just like Java did to manage the proliferation of names, it’s an imperative for Python to support this model. If pip can’t support developing namespace packages, then it is pip that is flawed, not the developers’ desire to use such packages. Is it really the case that namespace packages are too hard?

I agree --egg is a bad paradigm, but I would be strongly opposed to its removal. I’ve referred several developers who have encountered issues using pip -e. Our company uses namespace packages extensively. I personally work and develop in several namespaces:

• Zope and pyramid
• backports
• jaraco
• svg
• ore
• private namespaces

Namespaces allow packages to encapsulate names, maintain branding, share effort, but most importantly, scale.

If pip has painted itself into a corner by its installation technique (removing package files), then it should consider extending that installation technique to support this powerful model. I believe it would be a travesty for pip to declare defeat against this proven functionality. Pip should add this support before it removes the only viable workaround. Failing to do so will certainly lead to extra consternation within the community.

Unless setuptools get fixed…

If there’s anything that setuptools can do to help in this regard, then please do file tickets and submit pull requests. Describe what the defects are and how enhanced behavior would help. Changes that enable pip to function better would be highly valued and given priority.

[dstufft]

I’d like to push for this again.

I’ve just been made aware that Eric Snow backported the entire Python 3.x importlib machinery and it is available on PyPI (https://warehouse.python.org/project/importlib2/). This includes the ability to do implicit namespace packages i’m told.

This should hopefully allow for implicit namespace package support and make it possible to have namepsace packages that work across all methods of install.