Projects
New Ticket     Wiki     Browse Source     Timeline     Roadmap     Bug Reports     Search

Ticket #16723 (new enhancement)

Opened 2 months ago

Last modified 5 days ago

unify the python portgroups

Reported by: jmr@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.8.0
Component: base Version:
Keywords: Cc: ram@…, macsforever2000@…, jwa@…, myschizobuddy@…, blb@…, bryan@…, mcalhoun@…
Port:

Description

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.

Attachments

python-1.0.tcl (3.5 KB) - added by jmr@… 2 months ago.
python-1.0.2.tcl (8.8 KB) - added by mcalhoun@… 2 weeks ago.

Change History

  Changed 2 months ago by ram@…

  • cc ram@… added

Cc Me!

  Changed 2 months ago by macsforever2000@…

  • cc macsforever2000@… added

Cc Me!

follow-up: ↓ 4   Changed 2 months ago by macsforever2000@…

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

in reply to: ↑ 3   Changed 2 months ago by 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).

Changed 2 months ago by jmr@…

  Changed 2 months ago by jmr@…

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

  Changed 2 months ago by jwa@…

  • cc jwa@… added

Cc Me!

  Changed 2 months ago by myschizobuddy@…

  • cc myschizobuddy@… added

Cc Me!

  Changed 2 months ago by blb@…

  • cc blb@… added

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.

  Changed 2 months ago by 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
    }
}

  Changed 2 months ago by 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.

follow-up: ↓ 12   Changed 2 months ago by 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?

in reply to: ↑ 11 ; follow-up: ↓ 13   Changed 2 months ago by 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.

in reply to: ↑ 12   Changed 2 months ago by 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?

follow-up: ↓ 15   Changed 2 months ago by 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.

in reply to: ↑ 14   Changed 2 months ago by 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.

  Changed 3 weeks ago by bryan@…

  • cc bryan@… added

Cc Me!

  Changed 2 weeks ago by mcalhoun@…

  • cc mcalhoun@… added

Cc Me!

  Changed 2 weeks ago by 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.

Changed 2 weeks ago by mcalhoun@…

  Changed 5 days ago by jmr@…

  • version 1.7.0 deleted
  • milestone changed from MacPorts base enhancements to MacPorts 1.8.0

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

Note: See TracTickets for help on using tickets.