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.
