[MacPorts] #40347: py26-pyphant: use python PortGroup, merge multiple ports into subports, upgrade to version 1.0b2

[MacPorts]

#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