On Fri, Jun 22, 2012 at 12:12 AM, Chris McDonough <chr...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
