On Thursday, February 23, 2017, Xavier Fernandez <xav.fernan...@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.do...@python.org
> <javascript:_e(%7B%7D,'cvml','steve.do...@python.org');>> a écrit :
>
> On 23Feb2017 0914, Donald Stufft wrote:
>
>>
>> On Feb 23, 2017, at 11:04 AM, Nick Coghlan <ncogh...@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','ncogh...@gmail.com');>
>>> <mailto:ncogh...@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','ncogh...@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@python.org
> <javascript:_e(%7B%7D,'cvml','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
