+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 ?

Le 23 févr. 2017 19:19, "Steve Dower" <steve.dower@python.org> a écrit :
On 23Feb2017 0914, Donald Stufft wrote:

On Feb 23, 2017, at 11:04 AM, Nick Coghlan <ncoghlan@gmail.com
<mailto:ncoghlan@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
https://mail.python.org/mailman/listinfo/distutils-sig