python24-26 policy

[Rainer Müller]

On 2012-12-09 05:12, Ryan Schmidt wrote:
> On Dec 8, 2012, at 17:53, Joshua Root wrote:
>> With the unified portgroup there's almost no extra effort involved
>> in having them. I don't think there's any reason to drop them
>> until upstream does.
> 
> Users unfamiliar with the intricacies of the python ports in MacPorts
> may (and do) install "py-foo" and receive "py24-foo", and either
> assume that's the best we have to offer, or just run into problems
> because python 2.4 is old. We should be encouraging the use of python
> 2.7. Removing the python 24 subports from unified ports would
> facilitate that.

+1

Fewer versions reduce confusion for users.

This is especially a problem as other ports implement a different way to
select the version for modules/libraries. For python, the default for
py-foo is always py24-foo. For perl, requesting p5-foo installs the
p5.XY-foo depending on the +perl5.XY variant of the perl5 port. With
ruby, rb-foo refers to ruby 1.8 and rb19-foo to ruby 1.9, while no
rb18-foo exists at all.

I am not saying that the ways perl or ruby handle this are any better,
but it's confusing that this there is not one unique way to handle all this.

> If all the python modules were using the unified portgroup and had
> been doing so for awhile, we could just remove the py24 default in
> the portgroup, which was only there to help users upgrade from the
> pre-unified ports. But we still have many ports that are not
> unified.

While we have some ports that still depend on py-*, these are mostly
other non-unified python modules targeting python24. There are also
dependencies on ports that provide support for features merged into
later versions of python (for example py-bsddb, py-ctypes), these would
no longer be necessary when getting rid of python24.

Rainer