[140505] users/mojca/ports/python/py-GeomagPy/Portfile

Mojca Miklavec mojca at macports.org
Tue Sep 22 01:54:17 PDT 2015

On Mon, Sep 21, 2015 at 10:56 PM, Ryan Schmidt wrote:
> On Sep 21, 2015, at 6:13 AM, mojca at macports.org wrote:
>> Revision
>> 140505
>> Author
>> mojca at macports.org
>> Date
>> 2015-09-21 04:13:44 -0700 (Mon, 21 Sep 2015)
>> Log Message
>> mojca/py-geomagpy: upgrade, create an app
>> Modified: users/mojca/ports/python/py-GeomagPy/Portfile (140504 => 140505)
>>  PortSystem          1.0
>> +PortGroup           app 1.0
>>  PortGroup           python 1.0
>>  python.versions     27 34
>> +    # this could be a +gui option, enabled by default
>> +    app.name            MagPy-${python.version}
> Why should it be a variant -- why would anyone want to turn it off?

No particular reason (other than maybe people not wanting to see an
additional app on their launchpad). One issue is that I don't
particularly like the app.name to end with ${python.version} and would
perhaps prefer a standalone port called "geomagpy" or just "magpy"
with +python27/+python34 as a variant with the sole purpose of
packaging an app and depending on pyXY-geomagpy.

>> +    # this doesn't work because post-destroot did not finish yet and xmagpy doesn't exist
>> +    # app.executable    xmagpy-${python.version}
>> +    app.executable      ${python.pkgd}/magpy/gui/xmagpy.py
> There are two post-destroot blocks: one defined by the app portgroup and one defined by the python portgroup. The blocks run in the order in which they're defined. (Technically we don't guarantee that, but that's the order in which they've been running for awhile and I don't know of any plans to change it, since I'm sure that would break some things.) The app portgroup's post-destroot block gets defined as soon as the app portgroup is included, which is to say: first. It verifies that the app.executable specified exists. It doesn't yet, because it's a symlink that won't get created until the python portgroup's post-destroot block runs. The python portgroup's post-destroot block doesn't get defined until python.versions is set. So you could work around this problem by not including the app portgroup until after you set python.versions.

Thanks a lot for the exact explanation. I thought that something like
that was in the background, but I didn't take time to investigate.

> The solution you already used -- using the path of the real file, rather than a symlink to it -- may be the better fix.

OK. I'll leave it like that for now.

> But in fact, you must make an additional change, because as it is now, the py-geomagpy stub port fails to destroot:
> Error: Failed to destroot py-geomagpy: app.executable py-geomagpy does not exist

Thanks a lot for the notice. I didn't even try to install a barebone main port.

> This is because the app portgroup assumes that if you include it, you want it to install an app. You can solve this by either including the portgroup only inside the "if {${name} ne ${subport}}" block (this is probably messy; it's nicer to keep portgroups at the top of the file), or else set "app.create no" outside the "if" block and set "app.create yes" inside it. Use in a port with subports, where some ports don't want to create an app, is a use case I didn't consider when designing this portgroup. I should probably make the change I've talked about for awhile: change the default of app.create from yes to no, and update all ports using the portgroup to set it to yes where needed.

In all honesty I don't find it particularly nice to install an app
with every python version and I was thinking of creating a standalone
port (there are a few other ports that hardly do anything) and
generate a simple app there. The pyXY-foo ports were designed for
python libraries, not really for apps.


More information about the macports-dev mailing list