On 06/21/2012 10:30 AM, Nick Coghlan wrote: >> 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). I'm not sure under what circumstance 2 and 3 wouldn't do the same thing. Do you have a concrete idea? > 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 Yeah definitely a good start. - C
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4