On 17 November 2015 at 23:43, Thomas Güttler <guettl...@thomas-guettler.de> wrote: > > > Am 17.11.2015 um 13:48 schrieb Donald Stufft: >> >> >>> On Nov 17, 2015, at 6:33 AM, Nathaniel Smith <n...@pobox.com >>> <mailto:n...@pobox.com>> wrote: >>> >>> On Nov 16, 2015 11:57 PM, "Thomas Güttler" <guettl...@thomas-guettler.de >>> <mailto:guettl...@thomas-guettler.de>> wrote: >>> > >>> > > The job of a dependency is to enable tools like pip [#pip]_ to find >>> > > the right >>> > > package to install. >>> > >>> > My worries: AFAIK pip is not a library. >>> > >>> > I don't want to re-implement code to handle this pep. >>> > >>> > I would like to re-use. >>> > >>> > But AFAIK pip is not a library. >>> > >>> > I am stupid and don't know how to proceed. >>> > >>> > Please tell me what to do. >>> >>> Presumably there will be a dependency parser added to the 'packaging' >>> library, which already exists as a standard >>> place to stick stuff like this, so you'll just use that. (E.g. it's what >>> pip uses for PEP 440 version parsing today.) >>> >>> https://pypi.python.org/pypi/packaging > > Nice, a re-usable library :-) > > Since I don't see a reason for two implementations, I think the PEP should > provide a link to the implementation.
No, it shouldn't, as the whole point of these PEPs is to get away from implementation defined behaviours. If somebody can't implement their own library from scratch using just the material in the PEP, then the PEP is incomplete. However, it may be worth pointing to "packaging" from https://packaging.python.org/en/latest/current/ for the sake of folks implementing their own tooling (or adapting existing tools). At the moment, I believe the only reference is from the full project listing at https://packaging.python.org/en/latest/projects/#packaging Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
