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 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
