[Python-Dev] Status of packaging in 3.3

[Nick Coghlan]

On Fri, Jun 22, 2012 at 12:12 AM, Chris McDonough <chrism at plope.com> wrote:
> On 06/21/2012 09:29 AM, Nick Coghlan wrote:
>>>
>>> My only comment on that is this: Since this is a problem related to the
>>> installation of Python distributions, it should deal with the problems
>>> that
>>> Python developers have more forcefully than non-Python developers and
>>> non-programmers.
>>
>>
>> Thanks to venv, there's an alternative available that may be able to
>> keep both of us happy: split the defaults. For system installs, adopt
>> a vendor-centric, multi-language,
>> easy-to-translate-to-language-neutral-packaging mindset (e.g. avoiding
>> *.pth files by unpacking eggs to the file system). For venv installs,
>> do whatever is most convenient for pure Python developers (e.g.
>> leaving eggs packed and using *.pth files to extend sys.path within
>> the venv).
>
>
> I'd like to agree with this, but I think there's a distinction that needs to
> be made here that's maybe not obvious to everyone.
>
> A tool to generate an OS-specific system package from a Python library
> project should be unrelated to a Python distribution *installer*. Instead,
> you'd use related tools that understood how to unpack the distribution
> packaging format to build one or more package structures. The resulting
> structures will be processed and then eventually installed by native OS
> install tools.  But the Python distribution installer (e.g easy_install,
> pip, or some future similar tool) would just never come into play to create
> those structures.  The Python distribution installer and the OS-specific
> build tool might share code to introspect and unpack files from the
> packaging format, but they'd otherwise have nothing to do with one another.
>
> This seems like the most reasonable separation of concerns to me anyway, and
> I'd be willing to work on the code that would be shared by both the
> Python-level installer and by OS-level packaging tools.

Right, but if the standard library grows a dist installer (and I think
it eventually should), we're going to need to define how it should
behave when executed with the *system* Python.

That will give at least 3 mechanisms for Python code to get onto a system:

1. Python dist -> converter -> system package -> system Python path

2. Python dist -> system Python installer -> system Python path

3. Python dist -> venv Python installer -> venv Python path

While I agree that path 2 should be discouraged for production
systems, I don't think it should be prevented altogether (since it can
be very convenient on personal systems).

As far as the scope of the packaging utilities and what they can
install goes, I think the distutils2 folks have done a pretty good job
of defining that with their static metadata format:
http://alexis.notmyidea.org/distutils2/setupcfg.html#files

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia