I can envision a world where we migrate to space-separated everywhere, but I
think that would involve a decade of consumers supporting both until everyone
updates to a version of setuptools that emits spaces and I'm not sure it's
worth it.
Was anyone on the list involved with the decision to us
Sorry - yes you can absolutely participate. Reviews, issue triage, PRs, etc.
We haven't totally settled on a forum for chat, but given that this is an
international sprint even the "in the room" people are in two different
countries, so we're going to need that kind of communication.
For now, w
Yes that feels very dangerous to me. From the github thread it sounds like
setuptools *does* support it. I would be inclined to deprecate support for that
in setuptools if that's the case (though obviously since setup.py is a regular
python file you can write your own code to do whatever you wan
I strongly agree with this. I think a lot of the consumers of sdists are people
packaging projects for distributions (fedora, debian, arch, etc), and they want
to run the tests for their package.
I don't install tests for various reasons, including the fact that they are not
part of the public
That's what "calendar based versioning" means. It refers to the year of
release. See https://calver.org
On July 22, 2018 11:07:58 PM UTC, Bill Deegan wrote:
>I noticed the version number jumped from 10.0.1 -> 18.0
>Is there a reason for such?
>Change in version numbering policy which I missed re
I think the issue here is not your use of the "license" field (though using the
classifier-like syntax there is dubious), but the fact that you are specifying
an invalid classifier. The valid classifiers are enumerated, you can find them
here: https://pypi.org/classifiers/
I think the classifie
ge page?
2. Do I have to use a different extension for the README?
Regards,
Paul G.___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
