Python error activatin duplicity

[isaac@…]

I get an error while installing "duplicity" during the activation stage.

sudo port install duplicity
...
Error: Target org.macports.destroot returned: can't read "python.prefix": no such variable

Attaching full output with -d.

[jmr@…]

Please remember to fill in the Port field and cc the maintainer.

[singingwolfboy@…]

Confirmed: I'm seeing exactly the same issue on 10.6. I'm not sure how to solve it, though: even with the debug output, I'm not sure exactly where python.prefix is being called without being defined. (It doesn't help that I'm not very familiar with the internals of Macports.) I tried manually setting that variable, both in the main body of the port and in the post-destroot section (which seems to be where it's failing), but nothing changed. Anyone else want to take a look at this issue?

[jmr@…]

PortGroup was never designed to be used anywhere but right after PortSystem, for one thing.

[andreas.wilm@…]

Same here.

See also ticket #21126

[andreas.wilm@…]

Cc Me!

[owenc@…]

I'm seeing the exact same error.

I'm afraid I have no clue how this all works though. I've tried editing the Portfile but it seems to ignore those changes.

Log attached.

[owenc@…]

Cc Me!

[filippos@…]

Cc Me!

[barthelemy@…]

Same problem here. Note that it only appears when using python2.6. A workaround is then to use the python25 variant.

[barthelemy@…]

Cc Me!

[snc@…]

Cc Me!

[snc@…]

I'm not convinced the port needs to manually link the binaries. PortGroup python26 does this for you have linkbinaries set to yes.

Is simply removing your post-destroot acceptable?

[snc@…]

working copy having axed py25 portions

[singingwolfboy@…]

Replying to snc@…:

I'm not convinced the port needs to manually link the binaries. PortGroup python26 does this for you have linkbinaries set to yes. Is simply removing your post-destroot acceptable?

I didn't know about python.linkbinaries. Nifty! I looked over your diff, and I see two main problems:

• The port should be named "duplicity", not "py26-duplicity"
• The port does not create "/opt/local/bin/duplicity", it creates "/opt/local/bin/duplicity-2.6"

Duplicity is not a Python module, it's a separate program that happens to use Python as a dependency. It so happens that duplicity is written in Python, but I don't think that makes a difference. People who want to use duplicity for backup shouldn't have to care about which Python branch they use, although if they do care, they should be able to set it. (However, at this point, I think it's an acceptable price to drop multi-branch support in this port in order to just get duplicity working. Latest 2.X branch is a reasonable default.)

snc, would you be OK with me using your diff, but changing the name to "duplicity" and creating a post-destroot section to create a symbolic link from ${prefix}/bin/duplicity to ${prefix}/bin/duplicity-2.6 ?

[snc@…]

Replying to singingwolfboy@…:

snc, would you be OK with me using your diff, but changing the name to "duplicity" and creating a post-destroot section to create a symbolic link from ${prefix}/bin/duplicity to ${prefix}/bin/duplicity-2.6 ?

Feel free. I changed it to py26-duplicity because it became a python 26-only port through my diff. Granted you don't want a module but I feel that is what the PortGroup accomplishes.

[singingwolfboy@…]

committed in r64433

[michaelld@…]

Cc Me!