py26-pyphant: use python PortGroup, merge multiple ports into subports, upgrade to version 1.0b2

[mojca (Mojca Miklavec)]

I tried to create a port in r110552 replacing the following ports:

• py26-pyphant
• py26-pyphant-fmf
• py26-pyphant-imageprocessing
• py26-pyphant-osc
• py26-pyphant-statistics
• py26-pyphant-tools

by a single port with multiple subports for multiple python versions.

For some reason I had to comment out

OGLConstraint = wx._core._deprecated(Constraint,
                     "The OGLConstraint name is deprecated, use `ogl.Constraint` instead.")

from

${frameworks_dir}/Python.framework/Versions/2.7/lib/python2.7/site-packages/sogl/_composit.py

from the py-sogl package, but it's not yet clear to me why.

I'm still getting an error:

/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pyphant/wxgui2/wxPyphantApplication.py:70: wxPyDeprecationWarning: Using deprecated class PySimpleApp. 
  wx.PySimpleApp.__init__(self)

but that seems like an upstream problem. The app itself starts, but I don't really know how to use it. When launching the bundled app, it starts bouncing and doesn't seem to run.

I boldly tried to link against py27-wxpython-3.0. Given that the beta has been released recently, any remaining problems with 2.9 should really be fixed now since supporting 2.8 will be a nightmare.

Please take a look and try to fix the remaining problem. I have no idea how to use the software.

[petrrr]

Cc Me!

[mojca (Mojca Miklavec)]

See also: ​https://github.com/SGWissInfo/pyphant1/issues/48

[rowue@…]

committed fixed sogl version by r116606

[mojca (Mojca Miklavec)]

Thank you.

Do you happen to know why the new release (neither commits not the tag) isn't also on GitHub? ​https://github.com/SGWissInfo/sogl

Is the plan to switch to Python 2.7 exclusively once pyphant gets updated or is there some solid reason to keep support for Python 2.6?

I'm asking because you made a "weird" dependency on wxPython based on the version of Python. This shouldn't be necessary, wxPython 3.0 should work with Python 2.6 just as well if necessary, I just wasn't aware that any package would really benefit from it and I tried to avoid supporting all the versions from Python 2.4 up.

I would prefer not to add py26-wxpython-3.0, but I can do it if there's a strong reason to do it.

I checked and it seems that only py-pyphant depends on py-sogl.

[mojca (Mojca Miklavec)]

You can also replace the checksums with sha256.

[alexander.held@…]

Replying to mojca@…:

Do you happen to know why the new release (neither commits not the tag) isn't also on GitHub? ​https://github.com/SGWissInfo/sogl

I'm updating it right now on github, I just ran out of time yesterday.

Is the plan to switch to Python 2.7 exclusively once pyphant gets updated or is there some solid reason to keep support for Python 2.6?

I'm asking because you made a "weird" dependency on wxPython based on the version of Python. This shouldn't be necessary, wxPython 3.0 should work with Python 2.6 just as well if necessary, I just wasn't aware that any package would really benefit from it and I tried to avoid supporting all the versions from Python 2.4 up.

I would prefer not to add py26-wxpython-3.0, but I can do it if there's a strong reason to do it.

We want to keep python2.6 support for pyphant, since python2.6 is still very actively used in the scientific community (on Linux systems). The weird wxPython dependency comes from the fact that there was no py26-wxpython-3.0 macports package. I'm not so familiar with the macports community. Maybe python2.6 is not used there anymore. Then we could drop python2.6 support for the macports versions of sogl and pyphant, but we do not plan to drop python2.6 support for sogl or pyphant in general.

I checked and it seems that only py-pyphant depends on py-sogl.

As far as I know, sogl has been developed for the use in pyphant. I dont't know who else uses it now. Apparently no macports project.

[mojca (Mojca Miklavec)]

Replying to alexander.held@…:

Replying to mojca@…:

Do you happen to know why the new release (neither commits not the tag) isn't also on GitHub? ​https://github.com/SGWissInfo/sogl

I'm updating it right now on github, I just ran out of time yesterday.

Thanks for the information. I asked partially because the sources could also be fetched from GitHub. But that's not necessary. It should be whatever the author prefers.

Is the plan to switch to Python 2.7 exclusively once pyphant gets updated or is there some solid reason to keep support for Python 2.6?

I'm asking because you made a "weird" dependency on wxPython based on the version of Python. This shouldn't be necessary, wxPython 3.0 should work with Python 2.6 just as well if necessary, I just wasn't aware that any package would really benefit from it and I tried to avoid supporting all the versions from Python 2.4 up.

I would prefer not to add py26-wxpython-3.0, but I can do it if there's a strong reason to do it.

We want to keep python2.6 support for pyphant,

I didn't want to ask whether you want to drop support for python 2.6. I wanted to ask whether you have a reason to keep py26-pyphant working in MacPorts in addition to the future py27-pyphant.

The weird wxPython dependency comes from the fact that there was no py26-wxpython-3.0 macports package.

And that was only because there was no reason to add it until now. (Or rather: I wanted to avoid adding it just for the sake of having it there unless there was some reasonable use for it.)

I'm not so familiar with the macports community. Maybe python2.6 is not used there anymore.

Ports that existed "forever" usually just added support for a newer Python version when a new Python version has been released. For example, a random port py25-something would simply add py26-something without deleting py25-something when Python 2.6 came out. Same when Python 2.7 was released.

But there have been discussions about gradually removing all ports depending on Python 2.4, 2.5 and 2.6 (unless a port is incompatible with 2.7, but that sounds like something very outdated anyway), it's probably just that nobody took the time to do that.

So my main question was basically whether there is some need for py26-pythant in MacPorts or if py27-pyphant would do as well (once you release the next version of pyphant of course).

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.

[alexander.held@…]

Replying to mojca@…:

I didn't want to ask whether you want to drop support for python 2.6. I wanted to ask whether you have a reason to keep py26-pyphant working in MacPorts in addition to the future py27-pyphant.

...

But there have been discussions about gradually removing all ports depending on Python 2.4, 2.5 and 2.6 (unless a port is incompatible with 2.7, but that sounds like something very outdated anyway), it's probably just that nobody took the time to do that.

So my main question was basically whether there is some need for py26-pythant in MacPorts or if py27-pyphant would do as well (once you release the next version of pyphant of course).

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? I think I need more input in order to be able to decide whether we still need the py26-pyphant port after the new release.

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. Pyphant also has several setup.py files in one repository for the main package and the toolboxes for historic reasons. Is it possible to specify the location of the setup.py file within the repository?

[mojca (Mojca Miklavec)]

Replying to 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.)

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.

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.

[alexander.held@…]

Replying to mojca@…:

Replying to 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.

[mojca (Mojca Miklavec)]

Replying to alexander.held@…:

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.

When using the GitHub PortGroup there is no git involved at all. I can try myself if you don't manage to make it work.

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.

First of all: I wanted to say that linking py26-sogl against py26-wxpython-3.0 would be "impossible"/problematic now, when pyphant is not yet compatible with wxPython 3.0. That wouldn't work at all.

Once pyphant starts working with wxPython 3.0, there's no problem if py-sogl depends on py26-wxpython-3.0 in principle, but if the user has any given port installed that depends on wxPython 2.8, that will generate conflicts (and will generate nothing but confusion). In particular upgrading py26-pyphant will fail and users would need to manually force-remove some packages.

To avoid the conflict:

• One way is to provide port variants to depend on either wxPython 2.8 or 3.0. But that's just overcomplicating for no real benefit unless wxPython 3.0 support is buggy.
• Do what you did now: depend on wxPython 2.8 for Python 2.6 and on wxPython 3.0 for Python 2.7 also for pyphant, but that's suboptimal and ugly. Who would want to use X11 when Cocoa is available? (Other than maybe for testing something.)
• Simply drop support for Python 2.6 and automatically replace py26-pyphant with py27-pyphant when the user tries to upgrade.

[alexander.held@…]

We have moved pyphant and the toolboxes to the python port group. py-pyphant and the toolboxes py-pyphant-* have been updated to v1.0b3 and are working now with py26 and py27. py27-pyphant is linked against py27-wxpython-3.0 and py26-pyphant is linked against py26-wxpython-2.8. Both versions are working now, also when installed at the same time. The py26 subports might be dropped in the future.

We have also fixed the dependencies between py-pyphant and the toolboxes: Now the toolboxes depend on py-pyphant as it is in the source code. They are optional and not required by py-pyphant.

[mojca (Mojca Miklavec)]

Thank you very much.

Now, the carbon variant doesn't work properly because it's not connected to the choice of wxWidgets vs. wxGTK. If I install py27-pyphant, it starts X11 which makes no sense at all. Also, it's no longer carbon that's being used in wxWidgets-3.0, it's Cocoa, so the keyword is misleading as well. I fixed this somehow, even though my fix is not complete (it doesn't support wxPython-2.8 +carbon – I don't think it's worth the effort – and I could leave +carbon there for compatibility reasons.)

I created a suggestion for a port containing all subports together (combining all six ports in a single Portfile), see r117399 (​http://trac.macports.org/browser/users/mojca/wxports/python/py-pyphant/Portfile?rev=117399). Can you please take a look and commit it if you find it appropriate (or change whatever is missing)? (I can commit it as well, but I'm not the maintainer, so I would need maintainer's blessing in either case.)

I would like to suggest changing a few more things, but let's make it step-by-step. I'm really glad that it works with wxWidgets 3.0 now, I would only like to see the ports slightly simplified by merging them and thus leaving less maintenance burden in case of upgrades.

[rowue@…]

Replying to mojca@…:

Thank you very much.

Thanks a lot to you for your suggestions!

[wx, carbon, cocoa]

We will take care of the start up by the end of this week (finishing a project @work, working on submitting a paper). For carbon I think also that we should not put too much effort on this - I can't even work on it with my x86_64 machine. I think we should focus on future (perhaps simply drop this variant).

[Subports, maintainer]

I would like to suggest changing a few more things, but let's make it step-by-step. I'm really glad that it works with wxWidgets 3.0 now, I would only like to see the ports slightly simplified by merging them and thus leaving less maintenance burden in case of upgrades.

We also like to do this step by step, so we decided to work along wx-3.0 at first and after everything is fine and settled (including openening maintainership) move on to the subports. As i remember you also had some notices about our app bundle (which we have cleaned up a little bit by now), so I would suggest, we first fix the app bundle and afterwards move to subports.

Cheers,

Rolf (+Alex)

[mojca (Mojca Miklavec)]

Replying to rowue@…:

I think we should focus on future (perhaps simply drop this variant).

I totally support dropping wxpython-2.8. That would simplify the port a lot. You just need to make sure that you also change py-sogl where you declared a dependency on wxpython-2.8 (the only reason for that was pyphant that couldn't be built against wxwidgets 3.0 earlier).

If I was you, I would declare dependency on wxpython-3.0 (both in pyphant and sogl) and stop worrying.

We also like to do this step by step, so we decided to work along wx-3.0 at first and after everything is fine and settled (including openening maintainership) move on to the subports.

Subports are straightforward and don't require any larger abount of work or thinking, you take my example (and modify/ignore my changes for option names). Once you move, changing the rest will become easier as well.

As i remember you also had some notices about our app bundle (which we have cleaned up a little bit by now),

I wanted to clean exactly those bits and pieces that you already fixed. Earlier you manually copied files to assemble the app, now that happens in a Portgroup which is a lot cleaner. (Pyphant sources could in principle also build the app by themselves, but I wouldn't worry about that now. You can take care of that later.)

(Maybe I was talking about conflicts between Pyphant.app when using Python 2.6 vs. Python 2.7, but if you call the app Pyphant-2.X.app you are on the safe side, so I wouldn't bother right now either.)

so I would suggest, we first fix the app bundle and afterwards move to subports.

The app bundle basically works – apart from the fact that it tries to use X11 when there's no reason to do so. I would look into optimizing other issues, in particular it would be nice if there was no need for an intermediate shell script, to figure out if it's possible to change the icon etc., but those are minor issues. No hurry about those.

[mojca (Mojca Miklavec)]

May I please ask you to take another look at users/mojca/wxports/python/py-pyphant/Portfile?rev=120504?

The advantages are:

• py26 ports are automatically upgraded to py27
• no more need to keep the X11 baggage
• all ports combined together in a single file, a lot less maintainance, less error-prone

I would be really really grateful if that port could replace the six ports we have now.

[petrrr]

Cc Me!

[alexander.held@…]

Replying to mojca@…:

May I please ask you to take another look at users/mojca/wxports/python/py-pyphant/Portfile?rev=120504?

The advantages are:

• py26 ports are automatically upgraded to py27
• no more need to keep the X11 baggage
• all ports combined together in a single file, a lot less maintainance, less error-prone

I would be really really grateful if that port could replace the six ports we have now.

Thank you for your efforts on simplifying the ports. Unfortunately, my time is very limited currently and I have retracted my maintainer role for py-pyphant and the toolboxes. Openmaintainer has been added to the py-pyphant* ports, so your input is very welcome.

[mojca (Mojca Miklavec)]

I committed r122639. In case I broke something, please open a new ticket.