[Python-ideas] Make it optional

anatoly techtonik techtonik at gmail.com
Tue Feb 11 21:11:02 CET 2014


On Tue, Feb 11, 2014 at 6:53 PM, Hernan Grecco <hernan.grecco at 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.


More information about the Python-ideas mailing list