jupytext port build cannot find jlpm

[Ryan Schmidt]

On Mar 12, 2024, at 10:00, Jonathan Stickel wrote:
> 
> command not found: jlpm
> 
> Recommendations for how to resolve this issue?

One solution is to figure out where this program is being called in the source code, then patch it to use the program name as it appears in MacPorts (e.g. in this case to add the python version to the end).


> Is there a way to set an alias during the build phase?
> 
> alias jlpm="jlpm-${python.branch}"

I can't recall seeing a port that sets a shell alias so that may not be possible.

Some ports do create a directory in workpath (e.g. ${workpath}/bin), then create symlinks in there having the desired names, and add ${workpath}/bin to PATH. But that's probably not needed in this case since you already have a directory that contains the files with the desired names (below).


> Or add "${prefix}/Library/Frameworks/Python.framework/Versions/${python.branch}/bin" to the path? I haven't been successful implementing either approach.

You can find examples of how to do that by running:

port file all|sort -u|xargs grep '\sPATH='

Note that you want ${frameworks_dir}; don't assume its value is ${prefix}/Library/Frameworks


> I've been wondering if it is worth the trouble to create and maintain ports for some of these python packages. These days they are often using advanced python-internal build tools that are difficult to configure, while `pip install <package>` often just works. By comparison, there is a port for Julia but none of its packages, instead relying entirely on Julia's package manager. I'm curious about the thoughts of others on this matter.

I don't think it's been the intention to add all python modules to MacPorts. Rather, we add modules that are dependencies of other ports or are useful on their own (especially if requested by a user). 

The python portgroup was enhanced to support many of the new build systems. Check out the python.pep517_backend option.