#40347: py26-pyphant: use python PortGroup, merge multiple ports into subports, upgrade to version 1.0b2 ---------------------------+---------------------- Reporter: mojca@… | Owner: rowue@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: haspatch Port: py26-pyphant | ---------------------------+---------------------- Comment (by alexander.held@…): Replying to [comment:10 mojca@…]:
Replying to [comment:9 alexander.held@…]:
The macports site
[http://www.macports.org/ports.php?by=name&substr=py26-] still lists about 700 py26-* ports. To be honest, I don't see a reason to get rid of the older python variants if the port's source is still compatible, unless there is really not a single person out there still using python2.6. I have not been following these discussions. Do you have a link so that I can read about the reasons?
http://mac-os-forge.2317878.n4.nabble.com/116220-trunk-dports-python- td242217.html
For example: "Realistically, most modules below python27 should get axed."
(Most developers agree that python 2.4 modules should go, but it's not clean what to do about 2.5 and 2.6.)
Thank you for the reference.
Btw: for Pyphant we could test MacPorts packaging from any given
commit on GitHub. So you don't need to create a release just to test.
Thank you for the hint. Actually, we tried this already with `sogl`
but we did not succeed, since we do not have the setup.py file in the root of the repository and we could not figure out how to configure macports for this case.
Now that you have it on GitHub, I can take a quick look.
Is it possible to specify the location of the setup.py file within the repository?
I think you can change `worksrcdir`, but maybe there are other relevant variables.
I think we tried setting `worksrcdir` but then also all the git commands where executed inside the workdir. We did not investigate this further however.
Something else just came to my mind. If `py26-sogl` would depend on
`py26-wxpython-3.0` and `py26-pyphant` would depend on `py26-wxpython-2.8`, that wouldn't work anyway. So you may actually not declare a dependency on `py26-wxpython-3.0` in `py-sogl`, else you get an unavoidable conflict until you finish porting pyphant to wxWidgets 3.0. From that point of view having py26-wxpython-3.0 available would only benefit users of `py-sogl`, but at the same time render `py26-pyphant` useless. Let's postpone the discussion about py26 to the time when the next release of pyphant is nearly ready (even if that means tomorrow).
Support for Python 2.6 in new Pyphant means additional problems: if
users are forced to install `py26-wxpython-3.0`, this will conflict with all other ports depending on `py26-wxpython-2.8`. While `py27-wxpython-2.8` exists, that one conflicts with `py27-wxpython-3.0`. So users end up with endless conflicts that would be all need to be fixed manually. Agreed. I have scheduled the `pyphant` release for February 24th. Hopefully there will be no more delays. If I understood you correctly, the only way to keep `py26-pyphant` would be to link both `py26-sogl` and `py26-pyphant` against `py26-wxpython-2.8` and to link `py27-sogl` and `py27-pyphant` against `py27-wxpython-3.0`. At least this is how I intended to do it in the first place. But yes, let's delay the decision. Maybe it is not worth the effort keeping `py26-pyphant`. I just do not want to scare off people who insist on using python2.6 for a while. -- Ticket URL: <https://trac.macports.org/ticket/40347#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X