Re: [Distutils] Comments on PEP 426 and 459
On 7 Apr 2014 23:15, "Daniel Holth" wrote: > > I read through the latest versions of PEP 426 and 459 "Metadata 2.0 > and extensions". Here are my comments. > > The PEP suggests "setup.py dist_info" is a thing. Only "setup.py > egg_info" works. It might make sense to refactor bdist_wheel to > include a dist_info command, but if done badly it would break > distributions that rely on the pluggable nature of .egg-info > generation (most every part of the egg-info directory is written by a > separate plugin). > > Why do we care about "Source labels MUST be unique within each project > and MUST NOT match any defined version for the project."? Hmm, I think that stems from an earlier versions that allowed requiring a source label. I'll double check. > I still think meta distributions are unnecessary and hard to > understand. It's either a lot of trouble to try to discourage == > dependencies while still allowing them sometimes, or an > overcomplicated way to try to define requirements.txt 2.0 by allowing > distributions that aren't exactly distributions. PyObjC at least needs them, and things like OpenStack releases would need it (if published through PyPI). Meta distribution is an essential part of encouraging decoupled component design, without increasing the complexity of consuming an overall "release". > > This sounds like a pain: > " To avoid malicious hijacking of names, when interpreting metadata retrieved > from a public index server, automated tools MUST NOT pay any attention to > ``"provides"`` entries that do not correspond to a published distribution. " Yup. Necessary security feature for virtual provides in an untrusted environment, though. > > I'm not convinced that console scripts should not continue to be a > specially named entry point / export rather than their own very > similar thing. This is mostly a usability issue, but also relates to the stricter requirements for installers. >From a usability perspective, I don't believe users should have to learn about the arbitrary entry point support just to request install time script generation. "scripts are just a specific kind of plugin" is a case of confusing one possible implementation model with the semantic model uses actually care about (where scripts and plugins are different things). >From an installer perspective, the key difference is that the *installer itself* is one of the intended consumers of the metadata, so if the installer doesn't know how to handle script metadata, it should fail, rather than silently doing the wrong thing. By contrast, most other entry points are only relevant at *runtime* - the installer doesn't need to know anything about them. > > Overall both peps are quite good. We need to be able to put them to > use to advance our goal of providing a transparently > backwards-compatible Python packaging system. Yeah, agreed - we're to the point now where finalising these PEPs is pretty high on the packaging agenda :) > My peps repository on bitbucket has an updated json schema. Sweet, thanks. Cheers, Nick. > ___ > 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] What is the syntax for passing conditional non-extra dependencies in setuptools?
On 7 Apr 2014 15:09, "Daniel Holth" wrote: > > I think setuptools' :-separated environment markers mechanism is > great, and shouldn't need to be ratified anywhere. I also think the > actual environment markers specification is stable, although I noticed > the IPython wheel for example is using the deprecated .-separated > rather than _-separated identifiers. I think the one open question was whether or not to tolerate those dots from the previous iteration of the syntax where applicable. Cheers, Nick. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] install_requires vs. requires_dist, and setup.cfg
On 7 Apr 2014 00:59, "Marcus Smith" wrote: > > >> From what I understand in PEP 345, "Requires-Dist" is the name in PKG-INFO files for a distribution's dependencies on other distributions. > > > setuptools/distutils has never implemented "Requires-Dist" from PEP345 for PKG-INFO. > Otoh, wheel has, combined with PEP376, so you'll see it in *.dist-info METADATA files, when installing from wheels. > >> install_requires is the name of the keyword argument to setup() that specifies a dependency on another distribution. > > > yes > >> >> Sanity-check: This doesn't mean that one should call setup() with a "required_dist" keyword argument, right? > > > right > >> As I understand it. the setup.cfg revolution never happened, > > > right, see http://packaging.python.org/en/latest/future.html > > >> >> Also, I just created a trivial setup.py that contains an "install_requires" and doing "python setup.py develop --user" does seem to have created a PKG-INFO file, but it doesn't have a "Requires-Dist" line. > > > look for the "requires.txt" file. the dependency is in there. And for some additional context: the currently active metadata standards really consist of metadata 1.1 + the setuptools defined metadata files for dependencies and entry points. The 1.x metadata PEPs really don't stand on their own (not even 1.2). We know this is confusing, but it has been working well enough to bump metadata 2.0 down the priority list for the past several months. With any luck, we'll be able to thrash out the remaining issues here at PyCon and start to give people a clearer alternative (once the PEPs have been accepted and setuptools/pip/etc updated accordingly). Cheers, Nick. > > > > ___ > 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] Comments on PEP 426 and 459
I read through the latest versions of PEP 426 and 459 "Metadata 2.0 and extensions". Here are my comments. The PEP suggests "setup.py dist_info" is a thing. Only "setup.py egg_info" works. It might make sense to refactor bdist_wheel to include a dist_info command, but if done badly it would break distributions that rely on the pluggable nature of .egg-info generation (most every part of the egg-info directory is written by a separate plugin). Why do we care about "Source labels MUST be unique within each project and MUST NOT match any defined version for the project."? I still think meta distributions are unnecessary and hard to understand. It's either a lot of trouble to try to discourage == dependencies while still allowing them sometimes, or an overcomplicated way to try to define requirements.txt 2.0 by allowing distributions that aren't exactly distributions. This sounds like a pain: " To avoid malicious hijacking of names, when interpreting metadata retrieved from a public index server, automated tools MUST NOT pay any attention to ``"provides"`` entries that do not correspond to a published distribution. " I'm not convinced that console scripts should not continue to be a specially named entry point / export rather than their own very similar thing. Overall both peps are quite good. We need to be able to put them to use to advance our goal of providing a transparently backwards-compatible Python packaging system. My peps repository on bitbucket has an updated json schema. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] What is the syntax for passing conditional non-extra dependencies in setuptools?
On Mon, Apr 7, 2014 at 4:03 PM, Daniel Holth wrote:
> OK, it does in fact work that way; empty-string-before-colon specifies
> a default requirement with a marker.
>
> Parses out to the following _dep_map with 'None' representing 'not an
> extra dependency':
>
> {None: [Requirement.parse('coding'), Requirement.parse('stuff')],
> 'quux': [Requirement.parse('more-stuff')]}
>
> requirements.txt:
>
> coding
>
> [:sys_platform=='linux2']
> stuff
>
> [quux:sys_platform=='linux2']
> more_stuff
>
>
Huh. Either I did that intentionally and forgot about it, or it just fell
out as a brilliant accidental side effect of the orthogonal design of the
parsing functions. Either way, I feel like I did something smart there.
;-)
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] What is the syntax for passing conditional non-extra dependencies in setuptools?
OK, it does in fact work that way; empty-string-before-colon specifies
a default requirement with a marker.
Parses out to the following _dep_map with 'None' representing 'not an
extra dependency':
{None: [Requirement.parse('coding'), Requirement.parse('stuff')],
'quux': [Requirement.parse('more-stuff')]}
requirements.txt:
coding
[:sys_platform=='linux2']
stuff
[quux:sys_platform=='linux2']
more_stuff
On Mon, Apr 7, 2014 at 3:09 PM, Daniel Holth wrote:
> I think setuptools' :-separated environment markers mechanism is
> great, and shouldn't need to be ratified anywhere. I also think the
> actual environment markers specification is stable, although I noticed
> the IPython wheel for example is using the deprecated .-separated
> rather than _-separated identifiers.
>
> These kinds of conditionals are obviously an important feature for
> wheel and replace a common if/else statement inside setup.py, but can
> only be specified in wheels by placing a copy of the requirements in
> setup.cfg. It would be better if bdist_wheel could also just translate
> the setuptools requirements.txt to its own format.
>
> I assume extras_require = { ":sys_platform='win32'" :
> "wincertstore==0.2" } would be likely to specify a non-extra (the
> extra named '' or None?) dependency?
>
>
> On Thu, Mar 27, 2014 at 2:39 PM, PJ Eby wrote:
>> On Wed, Mar 26, 2014 at 11:29 PM, Daniel Holth wrote:
>>>
>>> How do I specify a conditional (marker-guarded) non-extra dependency
>>> in setuptools? The syntax for a conditional extra dependency is
>>> currently:
>>>
>>> extras_require = {
>>> "ssl:sys_platform=='win32'": "wincertstore==0.2",
>>> "certs": "certifi==1.0.1",
>>> },
>>
>>
>> I only implemented support via extras, and the feature wasn't officially
>> supported (still isn't, I don't think) because the PEP specifying the syntax
>> wasn't fully baked yet. I figured that if *only* setuptools itself used it,
>> then if the syntax changed only setuptools would break... but fix itself at
>> the same time.
>>
>> The same cannot be said for any other package, so use at your own risk. Or
>> better yet, don't use it. ;-)
>>
>> (At least, not until it's a documented feature w/a PEP-approved syntax.)
>>
>>
>>> ___
>>> 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] What is the syntax for passing conditional non-extra dependencies in setuptools?
I think setuptools' :-separated environment markers mechanism is
great, and shouldn't need to be ratified anywhere. I also think the
actual environment markers specification is stable, although I noticed
the IPython wheel for example is using the deprecated .-separated
rather than _-separated identifiers.
These kinds of conditionals are obviously an important feature for
wheel and replace a common if/else statement inside setup.py, but can
only be specified in wheels by placing a copy of the requirements in
setup.cfg. It would be better if bdist_wheel could also just translate
the setuptools requirements.txt to its own format.
I assume extras_require = { ":sys_platform='win32'" :
"wincertstore==0.2" } would be likely to specify a non-extra (the
extra named '' or None?) dependency?
On Thu, Mar 27, 2014 at 2:39 PM, PJ Eby wrote:
> On Wed, Mar 26, 2014 at 11:29 PM, Daniel Holth wrote:
>>
>> How do I specify a conditional (marker-guarded) non-extra dependency
>> in setuptools? The syntax for a conditional extra dependency is
>> currently:
>>
>> extras_require = {
>> "ssl:sys_platform=='win32'": "wincertstore==0.2",
>> "certs": "certifi==1.0.1",
>> },
>
>
> I only implemented support via extras, and the feature wasn't officially
> supported (still isn't, I don't think) because the PEP specifying the syntax
> wasn't fully baked yet. I figured that if *only* setuptools itself used it,
> then if the syntax changed only setuptools would break... but fix itself at
> the same time.
>
> The same cannot be said for any other package, so use at your own risk. Or
> better yet, don't use it. ;-)
>
> (At least, not until it's a documented feature w/a PEP-approved syntax.)
>
>
>> ___
>> 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] setup.py should use if __name__ == '__main__', right?
On 04/06/2014 09:04 PM, Asheesh Laroia wrote: > Hi nice distutils/PyPA people, > > I had a question that probably is worth showing up in the archives. Namely: > > It seems to me like bizarre bad form for the setup.py file to execute > what amounts to a main() function at import time. > > I presume this is just some kind of historical accident, and if the > early authors of the distutils docs were careful, they'd have recommended: > > from distutils.core import setup > > if __name__ == '__main__': > setup() # FIXME args > > > rather than just: > > from distutils.core import setup > > setup() # FIXME args > > > > Is that an accurate assessment? If so, that's great, because I plan to > remark on this bemusedly in my talk. If there is a reason it is the way > it is, however, then I will avoid making a joke that is wrong in an > important way. I don't think there's anything wrong with guarding the 'setup()' call with an 'if __name__ == "__main__"' (I have seen it done once or twice, and wouldn't object to someone advocating for it), but it isn't common practice, mostly because as Noah says there isn't any use case for importing setup.py, so in this particular instance it's un-useful boilerplate. Carl ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
