On 22.02.2007, at 18:35, Landon Fuller wrote:
On Feb 22, 2007, at 3:15 AM, Weissmann Markus wrote:
On 22.02.2007, at 03:54, Randall Wood wrote:
On 21 Feb 2007, at 20:43, Landon Fuller wrote:
On Feb 21, 2007, at 15:43, Weissmann Markus wrote:
Hi Douglas,
the soon-to-be-released version 1.4 of port will come with a
python 2.5 "port group". This will allow us to quickly produce
all the python vastness for python 2.5, too.
This might be a chance for newcomers to start coding Portfiles:
Basically you will have to replace the "GroupCode" line and the
name from the python 2.4 module Portfile to get a Python 2.5
one. People with the release candidate of 1.4 installed can
already hack away here (just don't put that code into the
repository yet - as long as 1.4 is not released)
I'm nonplussed by the massive code duplication that will occur
for py25 portfiles -- these will almost invariably be direct
copies of the py24 portfiles.
I'm not sure of the best solution -- perhaps python portgroup
can either point to 24 or 25?
I'm nonplussed (even upset) about broken python applications
because suddenly some py-* ports (read py-wxPython (there may be
others--I just don't know)) depend on python25 while other py-*
ports depend on python24.
The Fink developers hashed out this problem a few years back with
perl version 5.6 / 5.8 problems and concluded that the only road
forward was package duplication. I say duplicate the ports!
Although perhaps if we could create a Portfile.in type or style
of port that really generates multiple installable ports, we'd
have an easy solution...
The problem I see here is, that there is code that runs with 2.5
but not with 2.4 (and vice versa). Therefore we would at least
need a mechanism for also allowing the "cheap" duplicate ports
(for 2.4 and 2.5) as there will be modules that work with 2.4 in
version A and only with 2.5 with version B.
Could we perhaps somehow specify two port definitions in one
Portfile? Or find a good mechanism to include the common parts of
two Portfiles from a shared third file? Thoughts?
We could adapt the "include" mechanism such that one could include
other Ports (or meta ports) in the index. "Meta ports" would
require some analogue to PortSystem that informed the indexer that
it should not index that specific port.
This sounds like a good idea - the vim port already does something
like this (for it's quite impressive list of patchfiles). This could
look like this (for the py-crypto port):
- - - common.inc - - -
version 2.0.1
categories python security
platforms darwin
maintainers [EMAIL PROTECTED]
description collection of cryptographic algorithms and
protocols for python
long_description collection of cryptographic algorithms and
protocols...
homepage http://www.amk.ca/python/code/crypto.html
master_sites http://www.amk.ca/files/python/crypto/
distname pycrypto-${version}
checksums md5 4d5674f3898a573691ffb335e8d749cd
- - - Portfile-py24 - - -
PortSystem 1.0
include "common.inc"
name py24-crypto
PortGroup python24 1.0
- - - Portfile-py25 - - -
PortSystem 1.0
include "common.inc"
name py25-crypto
PortGroup python25 1.0
Those three files could live happily all together in the python/py-
crypto directory. The only mechanism we would need for this, is to
allow different names for Portfiles (so that two can sit side by side
in one place).
This solution is also quite nice as you could add a 'version' and
'checksum' key to one of the Portfiles, if e. g. the latest version
does not work e. g. on Python 2.4 anymore. This way you could still
share the 'description', 'homepage' etc.
-Markus
PS: This _might_ be a good opportunity to switch from the "Portfile"
name as an identifier for a port to something file-extension based,
like py25.port and py24.port.
---
Markus W. Weissmann
http://www.mweissmann.de/
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev