unify the python portgroups

[jmr@…]

The current practice of having separate ports of modules for each python version is awkward, and will get far worse now that python 2.6 and 3.0 are being released. Here is a portgroup that should be able to replace the current python25 and python24 groups, and can install for any combination of the available python versions at once via variants.

[ram@…]

Cc Me!

[macsforever2000@…]

Cc Me!

[macsforever2000@…]

What will happen in the case of py-ctypes which is built into Python 2.5+?

[jmr@…]

Replying to macsforever2000@…:

What will happen in the case of py-ctypes which is built into Python 2.5+?

I suppose that ports that depend on it should only do so if a python <= 2.4 variant is set. And also py-ctypes should not declare python25+ variants (a capability yet to be added to the portgroup).

[jmr@…]

Updated with procs for setting the supported and default python versions.

[jwa@…]

Cc Me!

[myschizobuddy@…]

Cc Me!

[blb@…]

First issue is the set of "breakout" ports, those normally a part of Python but removed for dependency reasons (see ticket #12369). Since those are versioned along with Python itself, and we don't want to be setting version in a variant section, I think they'll have to remain py##- ports unless there's a better way to handle them. Or integrate back into Python and incur the heavy dependencies for them all.

[jmr@…]

Right, short of resolving #126, I guess there will need to be stuff like this in the portfiles:

foreach v {25 26 30} {
    if {[variant_isset python${v}]} {
        depends_lib-append port:py${v}-hashlib
    }
}

[blb@…]

Testing looks good so far, I have (among other ports in this test install):

$ port-test installed py*
The following ports are currently installed:
  py-mx-base @3.1.1_0+python25+python26 (active)
  py-setuptools @0.6c8_0+python25+python26 (active)
  py25-hashlib @2.5.2_0 (active)
  py25-zlib @2.5.2_0 (active)
  py26-hashlib @2.6_0 (active)
  py26-zlib @2.6_0 (active)
  python25 @2.5.2_5+darwin_9 (active)
  python26 @2.6_2+darwin_9 (active)

I used the foreach to define py25- and py26- dependencies for py-setuptools:

$ port-test info +python25 +python26
py-setuptools @0.6c8 (python, devel)
Variants:    python24, +python25, +python26
...
Build Dependencies: py25-hashlib, py26-hashlib
Library Dependencies: python25, python26, py25-zlib, py26-zlib

Now we should probably find some more esoteric modules for edge-case testing.

Obviously in this test install I have defined the py26- ports, created a python26 portgroup, and replaced the python portgroup with the one here.

[blb@…]

What's the purpose of proc python.versions and proc python.default_version? Since there are globals with the same name, which are initialized, and all use of these names is by the variable, aren't they unnecessary?

[jmr@…]

Replying to blb@…:

What's the purpose of proc python.versions and proc python.default_version? Since there are globals with the same name, which are initialized, and all use of these names is by the variable, aren't they unnecessary?

The variable and proc with the same name is just like all the regular portfile 'keywords'. They're there so that the port can specify a different set of supported python versions, and a different default version.

[blb@…]

Replying to jmr@…:

The variable and proc with the same name is just like all the regular portfile 'keywords'. They're there so that the port can specify a different set of supported python versions, and a different default version.

So it's like portmain.tcl's options ... only more directly then?

I can definitely understand the occasional need to change which python versions are supported by a module, but I would think the default version should be coming from elsewhere and not settable by a port?

[blb@…]

If #14615 gets committed, then python.default_version should come from its .current; then python_select would be the way of selecting the default version for the command line and for installing python modules.

[jmr@…]

Replying to blb@…:

If #14615 gets committed, then python.default_version should come from its .current; then python_select would be the way of selecting the default version for the command line and for installing python modules.

Then, the only problem then is what to do if the default version isn't in the list of supported versions.

[bryan@…]

Cc Me!

[mcalhoun@…]

Cc Me!

[mcalhoun@…]

Attached is a modification of first python-1.0.tcl.

The idea is to take advantage of the fact that all the pythons are
now frameworks, which handle multiple versions well.

• Nothing gets installed into ${prefix}/bin except links to ${frameworks_dir}/Python.framework/Versions/Current/bin
• Nothing gets installed into ${prefix}/share/man except links to ${frameworks_dir}/Python.framework/Versions/Current/share/man

Now, python_select automatically gives us the correct packages.

[jmr@…]

I discussed this with blb on IRC, and we concluded that this approach ultimately isn't practical without a fix for #126.