[Distutils] distlib 0.1.6 released on PyPI
I've just released version 0.1.6 of distlib on PyPI [1]. For newcomers, distlib is a library of packaging functionality which is intended to be usable as the basis for third-party packaging tools. The main changes in this release are as follows: Updated the binary launcher executables, because the wrong variant of these was shipped with the previous release. A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker! [3] Regards, Vinay Sajip [1] https://pypi.python.org/pypi/distlib/0.1.6 [2] http://pythonhosted.org/distlib/overview.html#change-log-for-distlib [3] https://bitbucket.org/pypa/distlib/issues/new ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] migration path for entry_points?
ok, so PEP459 has exports: http://www.python.org/dev/peps/pep-0459/#the-exports-extension and distlib seems to be implementing them. and exports seem to be entry points 2.0. so theoretically, when PEP426/PEP459 becomes live what does that mean for setuptools-based projects? (I understand that we might not have a clear idea now, but just trying to narrow down the possibilities) 1) the setuptools entry_points keyword (and pkg_resources api) gets re-implemented to understand PEP459 exports? or 2) entry_points keeps the old implementation, and possibly tools are written to handle the old and new metadata? or 3) entry_points are stranded, and consumers have to rewrite setup.py files to use some new keyword that understands PEP459 or 4) something altogether different... as for why I'm asking, pip itself is considering command extensions, so it's a direct practical matter for us. Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] migration path for entry_points?
It's nice to have that split up into lots of more focused documents. The comment I have is that I think entry points sometimes have multiple values with the same name (a list or multidict instead of a simple dict) although I'm not sure how common that is... Tools should just do automatic conversion of entry_points.txt to the new metadata format when .dist-info is in use. On Tue, Dec 31, 2013 at 3:05 PM, Marcus Smith qwc...@gmail.com wrote: ok, so PEP459 has exports: http://www.python.org/dev/peps/pep-0459/#the-exports-extension and distlib seems to be implementing them. and exports seem to be entry points 2.0. so theoretically, when PEP426/PEP459 becomes live what does that mean for setuptools-based projects? (I understand that we might not have a clear idea now, but just trying to narrow down the possibilities) 1) the setuptools entry_points keyword (and pkg_resources api) gets re-implemented to understand PEP459 exports? or 2) entry_points keeps the old implementation, and possibly tools are written to handle the old and new metadata? or 3) entry_points are stranded, and consumers have to rewrite setup.py files to use some new keyword that understands PEP459 or 4) something altogether different... as for why I'm asking, pip itself is considering command extensions, so it's a direct practical matter for us. Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] migration path for entry_points?
On 1 Jan 2014 06:58, Daniel Holth dho...@gmail.com wrote: It's nice to have that split up into lots of more focused documents. Yeah, I was really happy with how breaking things up into multiple extensions worked out. I'm still pondering the question of whether or not to aim for the updated installation database format (with a check for an sqlite DB in each path entry before looking directly at the metadata files) in the metadata 2.0 time frame. It's a potentially preferable approach to speeding up runtime lookups over extracting additional per-distribution data files. Maybe it's worth at least defining that as a *goal* and then deciding the time frame for when we want to get there? The comment I have is that I think entry points sometimes have multiple values with the same name (a list or multidict instead of a simple dict) although I'm not sure how common that is... If the current format allows repeated keys with different values, we may need to allow lists as values in addition to strings in the PEP 459 approach. Tools should just do automatic conversion of entry_points.txt to the new metadata format when .dist-info is in use. Yep, as with other fields, my aim is to create a format that can be derived from the existing setuptools metadata. That way, PyPI can publish it even for projects that only upload metadata using the current setuptools formats. Cheers, Nick. On Tue, Dec 31, 2013 at 3:05 PM, Marcus Smith qwc...@gmail.com wrote: ok, so PEP459 has exports: http://www.python.org/dev/peps/pep-0459/#the-exports-extension and distlib seems to be implementing them. and exports seem to be entry points 2.0. so theoretically, when PEP426/PEP459 becomes live what does that mean for setuptools-based projects? (I understand that we might not have a clear idea now, but just trying to narrow down the possibilities) 1) the setuptools entry_points keyword (and pkg_resources api) gets re-implemented to understand PEP459 exports? or 2) entry_points keeps the old implementation, and possibly tools are written to handle the old and new metadata? or 3) entry_points are stranded, and consumers have to rewrite setup.py files to use some new keyword that understands PEP459 or 4) something altogether different... as for why I'm asking, pip itself is considering command extensions, so it's a direct practical matter for us. Marcus ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] migration path for entry_points?
let's consider 2 cases 1) someone publishes an sdist extension, SomeExtension-1.0.tar.gz up on pypi, that uses the setuptools entry_points keyword 2) someone publishes a wheel extension, SomeExtension-1.0.whl that has a traditional entry_points.txt file baked into it. and then PEP426 goes live, and pip/setuptools refactor themselves to be compliant, i.e. setuptools starts generating 2.0 metadata, and pip (via a new pkg_resources, distlib, or some other alternative) is able to process 2.0 metadata. for #1, during installation, I imagine the new setuptools would build the sdist (and any entry_point declarations) using 2.0 metadata. for #2, the pip installer would be responsible for converting entry_points.txt during the install (or maybe just forcing a bdist_wheel rebuild when it detects metadata 2.0) On Tue, Dec 31, 2013 at 1:35 PM, Marcus Smith qwc...@gmail.com wrote: Tools should just do automatic conversion of entry_points.txt to the new metadata format when .dist-info is in use. Yep, as with other fields, my aim is to create a format that can be derived from the existing setuptools metadata. That way, PyPI can publish it even for projects that only upload metadata using the current setuptools formats. ok, but to be clear about the *usage* of the entry_points setup keyword... that's the user question. Should someone feel ok with adopting this now? It sounds like you're saying yes. setuptools users should assume either: a) new-style tool consumers of metadata will auto-convert old-style entry points b) setuptools will update the implementation of entry_points to produce be PEP459 compliant ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Major update to the metadata 2.0 draft PEPs
On Sat, Dec 21, 2013 at 9:46 AM, Nick Coghlan ncogh...@gmail.com wrote: I've just published the first draft of the metadata 2.0 spec that moves all of the fields that aren't part of the core metadata or potentially needed for dependency resolution out to a separate standard metadata extensions PEP. Yay! I think this makes PEP 426 itself substantially less overwhelming, and also provides convenient names to refer to the various other subsets of the metadata. Indeed! Metadata 2.0: http://www.python.org/dev/peps/pep-0426/ Versioning: http://www.python.org/dev/peps/pep-0440/ Standard Extensions: http://www.python.org/dev/peps/pep-0459/ I have only been skimming these so far, will comment more later, but I just want to mention that for standard extensions, what is the rationale for not defining e.g. commands as exports? Or for that matter, defining hooks as exports? Both commands and hooks have a payload that's the same as an export payload, i.e., a reference to an importable object. I think it'd be good for them to be defined in terms of exports in order to reduce duplication of concepts and implementations, as well as providing a PEP-defined example of how to use export groups and export names effectively. (Also, noting the mapping of current script export namespaces to the new metadata would be helpful for people implementing translation tools from setuptools metadata.) Last but not least, some of the export examples should use dotted post-module names (e.g. some.module:RandomClass.a_class_method) to highlight that qualified names can be used there. (Yes, the spec *says* qualified names, but it's the sort of thing that people overlook when the examples are all of unqualified simple names.) ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
