Flexibility of something is the fact that you are not forced to use it in some unnatural way. I'd say that most PEPs related to core Python are flexible, but I am not sure about the rest. PEPs are made to resolve ambiguities. But it doesn't mean limiting flexibility and setting hard limitation. What is hard limitation standard? For example, marking version you can not parse as pre-release. PIP actually does this, which prevents all packages with versions that are not comply with "versioning PEP" from installing. "pre-release" is a feature. Inflexible, tempting to guess, getting in a way, implicit and confusing. I just filled three or four bugs about it. How come that it appeared at all? Well, because it is useful. In some cases. But the problem is that it affects you even if you don't need it. "Make it optional" is a very good principle for those cases when you can not predict how users are going to use your feature and if they need it at all. -- anatoly t.
Am 11.02.2014 05:35, schrieb anatoly techtonik:
Flexibility of something is the fact that you are not forced to use it in some unnatural way. I'd say that most PEPs related to core Python are flexible, but I am not sure about the rest.
PEPs are made to resolve ambiguities. But it doesn't mean limiting flexibility and setting hard limitation. What is hard limitation standard? For example, marking version you can not parse as pre-release. PIP actually does this, which prevents all packages with versions that are not comply with "versioning PEP" from installing.
"pre-release" is a feature. Inflexible, tempting to guess, getting in a way, implicit and confusing. I just filled three or four bugs about it. How come that it appeared at all? Well, because it is useful. In some cases. But the problem is that it affects you even if you don't need it.
"Make it optional" is a very good principle for those cases when you can not predict how users are going to use your feature and if they need it at all.
I have no idea what you are talking about. Care to give some context? Georg
On 11 February 2014 07:20, Georg Brandl <g.brandl@gmx.net> wrote:
"Make it optional" is a very good principle for those cases when you can not predict how users are going to use your feature and if they need it at all.
I have no idea what you are talking about. Care to give some context?
Anatoly has just raised a series of issues against pip, all essentially reiterating the same point that he doesn't like pip's new handling of prerelease vs release versions (which was thrashed out and agreed in a PEP) I assume he's trying to get support for some vague meta-point here in the hope that by doing so he'll feel justified in arguing further on the pip issues :-( Paul
On Tue, Feb 11, 2014 at 10:48 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 11 February 2014 07:20, Georg Brandl <g.brandl@gmx.net> wrote:
"Make it optional" is a very good principle for those cases when you can not predict how users are going to use your feature and if they need it at all.
I have no idea what you are talking about. Care to give some context?
Anatoly has just raised a series of issues against pip, all essentially reiterating the same point that he doesn't like pip's new handling of prerelease vs release versions (which was thrashed out and agreed in a PEP) I assume he's trying to get support for some vague meta-point here in the hope that by doing so he'll feel justified in arguing further on the pip issues :-(
Right. Smart people invented prerelease feature for PyPI, which works the following way: - if pip thinks that your version is not PEP compliant, it won't install it, because it thinks that everything what is not PEP aware is prerelease I think that final decision whatever package version is prerelease or not should be made by package maintainer, and (s)he should have a final judgement over this fact. But inventors of prerelease feature didn't even think that people may not want and still don't want this features. That's why I proposed "Make it optional" principle as an engineering practice for solutions that affect the whole net.
On Tue, Feb 11, 2014 at 11:33 AM, anatoly techtonik <techtonik@gmail.com>wrote:
I think that final decision whatever package version is prerelease or not should be made by package maintainer, and (s)he should have a final judgement over this fact. But inventors of prerelease feature didn't even think that people may not want and still don't want this features.
But package maintainers have the final judgement! A package is NOT a pre-release if it has a PEP 440 compliant version number without any pre-release or development segment. A simple rule. The problem is how to deal with old packages with non compliant versions which now are not get installed by default. I would say: - If you are the maintainer of the legacy package, just release a new version with a compliant version. - If you are the maintainer of a project that needs this legacy package, just adjust your requirements file as described in [0] The versioning scheme proposed in PEP440 has a lot of advantages (which are described in the PEP). But it comes with some rules that we need to comply. cheers, Hernán [0] http://www.pip-installer.org/en/latest/logic.html#pre-release-versions On Tue, Feb 11, 2014 at 11:33 AM, anatoly techtonik <techtonik@gmail.com>wrote:
On Tue, Feb 11, 2014 at 10:48 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 11 February 2014 07:20, Georg Brandl <g.brandl@gmx.net> wrote:
"Make it optional" is a very good principle for those cases when you can not predict how users are going to use your feature and if they need it at all.
I have no idea what you are talking about. Care to give some context?
Anatoly has just raised a series of issues against pip, all essentially reiterating the same point that he doesn't like pip's new handling of prerelease vs release versions (which was thrashed out and agreed in a PEP) I assume he's trying to get support for some vague meta-point here in the hope that by doing so he'll feel justified in arguing further on the pip issues :-(
Right. Smart people invented prerelease feature for PyPI, which works the following way:
- if pip thinks that your version is not PEP compliant, it won't install it, because it thinks that everything what is not PEP aware is prerelease
I think that final decision whatever package version is prerelease or not should be made by package maintainer, and (s)he should have a final judgement over this fact. But inventors of prerelease feature didn't even think that people may not want and still don't want this features.
That's why I proposed "Make it optional" principle as an engineering practice for solutions that affect the whole net. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, Feb 11, 2014 at 6:53 PM, Hernan Grecco <hernan.grecco@gmail.com> wrote:
I think that final decision whatever package version is prerelease or not should be made by package maintainer, and (s)he should have a final judgement over this fact. But inventors of prerelease feature didn't even think that people may not want and still don't want this features.
But package maintainers have the final judgement! A package is NOT a pre-release if it has a PEP 440 compliant version number without any pre-release or development segment. A simple rule.
Except that for some of my projects history, documentation, milestones and tags all use (semantic) versioning, which appears to be incompatible with this PEP.
The problem is how to deal with old packages with non compliant versions which now are not get installed by default.
Although it is out of scope of this idea, but can you tell me why you do you want to deal with non compliant versions? I hope there are better arguments that just for this fuzzy warm feeling of total compliance.
I would say: - If you are the maintainer of the legacy package, just release a new version with a compliant version. - If you are the maintainer of a project that needs this legacy package, just adjust your requirements file as described in [0]
You forgot to mention changing current development instructions, development toolchain to rewrite some internal logic to sort old and new versions correctly. No matter how big the PEP 440 is going to get, it unlikely to cover all use cases that people have for package versions. Look at Ubuntu vs Debian if you want to get impression what kind of versioning scheme is pretty possible when you have to maintain several custom packages for different projects against upstream. You can really provide an ton of useful advice to me, but really - just let people handle it themselves - make it optional.
The versioning scheme proposed in PEP440 has a lot of advantages (which are described in the PEP). But it comes with some rules that we need to comply.
I am not sure what advantages are you talking about. They seem to be pretty subjective and for some specific projects I just want to opt-out.
anatoly techtonik writes:
Except that for some of my projects history, documentation, milestones and tags all use (semantic) versioning, which appears to be incompatible with this PEP.
There's some sort of feature for mapping semantic ("generic") version tags to PEP-compatible version strings. Please find out what it is, *before* you reply, and explain why it doesn't work for you.
No matter how big the PEP 440 is going to get, it unlikely to cover all use cases that people have for package versions.
It's unlikely to get bigger. PEP 440 is not just about coming up with a regular notation for versions; it is also about dependency computations. There's enough junk in there for that.
anatoly techtonik writes:
PEPs are made to resolve ambiguities. But it doesn't mean limiting flexibility and setting hard limitation. What is hard limitation standard? For example, marking version you can not parse as pre-release. PIP actually does this, which prevents all packages with versions that are not comply with "versioning PEP" from installing.
You say you've filed a bug. That's the right thing to do. AFAICT, to the extent that it really *prevents* installation, it doesn't conform to PEP 440 (see "Handling of Pre-Releases" and "Direct References" in the PEP). Since it is arguably a bug, it doesn't need discussion here.
participants (5)
-
anatoly techtonik -
Georg Brandl -
Hernan Grecco -
Paul Moore -
Stephen J. Turnbull