[Distutils] distlib and wheel metadata

[Wes Turner]

On Thursday, February 23, 2017, Xavier Fernandez <xav.fernandez at gmail.com>
wrote:

> +1 also.
> This whole double requirement feels over-complicated for what seems like a
> rather small usecase: it would be interesting to have a few stats on the
> number of packages concerned by this pinning (maybe just scan all the last
> uploaded wheels of each package ?).
>
>


> And if one needs to classify packages type, why not add a new high level
> trove classifier ?
>

+1 This could be accomplished with a trove classifier (because Entity
Attribute boolean-Value)

The component/library, application, metapackage categorical would require
far more docs than:

    pip install --ignore-versions metapkgname

Which is effectively, probably, maybe the same? as:

    pip install metapkg
    pip install --upgrade __ALL__


... say, given that metapkgname requires (install_requires) ipython, and
the requirements.txt is:

  metapkgname # ipython==4.2
  ipython

If pip freeze returns:

  ipython
  metapkgname

And I then:

  pip freeze -- | xargs pip install --upgrade

Haven't I then upgraded ipython past the metapackage pinned version, anyway?

http://stackoverflow.com/questions/2720014/upgrading-all-packages-with-pip

The best workaround that I'm aware of:
- Create integration test and then build scripts
- Run test/build script in a container
- Change dependencies, Commit, Create a PR, (e.g. Travis CI runs the
test/build/report/post script), Review integration test output

What integration tests do the RPM/DNF package maintainers run for, say,
django, simplejson, [and psycopg2, for django-ca]? If others have already
integration-tested even a partially overlapping set, that's great   and it
would be great to be able to store, share, and search those build artifacts
(logs, pass/fail).


Additionally, practically, could we add metadata pointing to zero or more
OS packages, per-distribution? How do I know that there's probably a
somewhat-delayed repackaging named "python-ipython" which *might* work with
the rest of the bleeding edge trunk builds I consider as stable as
yesterday, given which tests?


>
> Le 23 févr. 2017 19:19, "Steve Dower" <steve.dower at python.org
> <javascript:_e(%7B%7D,'cvml','steve.dower at python.org');>> a écrit :
>
> On 23Feb2017 0914, Donald Stufft wrote:
>
>>
>> On Feb 23, 2017, at 11:04 AM, Nick Coghlan <ncoghlan at gmail.com
>>> <javascript:_e(%7B%7D,'cvml','ncoghlan at gmail.com');>
>>> <mailto:ncoghlan at gmail.com
>>> <javascript:_e(%7B%7D,'cvml','ncoghlan at gmail.com');>>> wrote:
>>>
>>> Redistributors may *ask* a publisher to reclassify their project as a
>>> library or a devtool (and hence also avoid pinning their dependencies
>>> in order to make integration easier), but publishers will always have
>>> the option of saying "No, we want to you to treat it as an
>>> application, and we won't help your end users if we know you're
>>> overriding our pinned dependencies and the issue can't be reproduced
>>> outside your custom configuration".
>>>
>>
>>
>> This whole discussion feels like trying to overcomplicate something
>> that’s already not a simple to solve a problem that I don’t think is
>> really that widespread. My estimation is that 99% of people who are
>> currently using ``==`` will just immediately switch over to using
>> whatever flag we provide that allows them to still do that. Adding a “do
>> the thing I asked for” detritus to the project seems like a bad idea.
>>
>> It’s not really any different than if a project say, only released
>> Wheels. While we want to encourage projects to release sdists (and to
>> not ping versions) trying to enforce that isn’t worth the cost. Like
>> most packaging issues, I think that it’s best solved by opening up
>> issues on the offending project’s issue tracker.
>>
>
> +1. This has been my feeling the entire time I spent catching up on the
> thread just now.
>
> As soon as "user education" becomes a requirement, we may as well do the
> simplest and least restrictive metadata possible and use the education to
> help people understand the impact of their decisions.
>
> Cheers,
> Steve
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> <javascript:_e(%7B%7D,'cvml','Distutils-SIG at python.org');>
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170224/4fc883fe/attachment.html>