Advice on distributing a project

[Craig Treleaven]

> On Jun 14, 2018, at 1:58 PM, Langer, Stephen A. (Fed) <stephen.langer at nist.gov> wrote:
> 
> On 6/13/18, 8:37 PM, "Craig Treleaven" <ctreleaven at macports.org> wrote:
> 
>> On Jun 13, 2018, at 6:35 PM, Rainer Müller <raimue at macports.org> wrote:
>> 
>> On 2018-06-13 21:37, Langer, Stephen A. (Fed) wrote:
>>> (2) Package all of the compiled libraries and dependencies into a Mac-like app and distribute binaries, but not a portfile.  Will "port pkg"  do this if I write a portfile for the project?  Can I tell it to include the vtk libraries that have been built outside of MacPorts?
>> 
>> You could use 'sudo port mpkg', which creates a single .pkg installer
>> that includes the files for the port and all of its dependencies. This
>> assumes that you have a port that provides the required vtk libraries.
>> It is not possible to include extra files that are not provided by a port.
>> 
>> If you are going to distribute this installer, please use a prefix other
>> than /opt/local for it, to avoid a collision for users that also use
>> MacPorts.
>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fguide.macports.org%2F%23using.binaries.binary-packages&data=02%7C01%7Cstephen.langer%40nist.gov%7C13c0320a0b5d4cbf5f6008d5d18ef78f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636645334320959905&sdata=VhTttsZ3dydXb7vatIRiExciRimMpMa38%2Bj6zLNeTZE%3D&reserved=0
> 
>    If you anticipate that some or all the users will have MacPorts installed, creating an installer with MacPorts _may_ lead to problems even though you use a non-default prefix when creating your installer.  That non-default prefix is where your packaged software ends up on the user’s system.  If your packaged software looks for utilities (or libraries) at run-time, the user’s PATH could lead to version conflicts.  Hopefully this would not affect you but it could lead to ‘wild-goose-chasing’ bugs.  Something to give thought to before going down this path.
> 
>    Re vtk, or any other dependency, you can create/modify any of the ports for the deps so as to get the version you want.  See the guide section:
> 
>    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fguide.macports.org%2F%23development.local-repositories&data=02%7C01%7Cstephen.langer%40nist.gov%7C13c0320a0b5d4cbf5f6008d5d18ef78f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636645334320959905&sdata=uo57kLPv9JZjJnZDb9%2FTIVhAcqmojVI03kbfUhWjTJQ%3D&reserved=0
> 
>    In addition to the guide section that Rainer linked, you might want to review the following wiki page.  I’ve written up some tips and tricks…mostly to aid my own memory.  Contributions encouraged!
> 
>    https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.macports.org%2Fwiki%2Fhowto%2FCreateInstallers&data=02%7C01%7Cstephen.langer%40nist.gov%7C13c0320a0b5d4cbf5f6008d5d18ef78f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636645334320959905&sdata=5G7LcSLCO%2FSWO2W4b4TMIzWp2JOHMONoGWuHIjfnLq0%3D&reserved=0
> 
>    If you get into the process and have questions or issues, don’t hesitate to post to this mailing list.  I and others would be happy to try to help.
> 
>    Craig
> 
> 
> Thanks for the advice.  If I make a new non-standardly located macports directory on my system, build my program and all of its dependencies in that directory (including dependencies that aren't packaged with macports), and then package it with "port mpkg", is that guaranteed to avoid conflicts on users' systems?  I'd be using both a non-default installation prefix in my portfile, and also a non-default version of macports to build it.
> 

I can’t “guarantee” that there won’t be conflicts—I don’t know what you are trying to package!

If your software consists of a few C++ programs that link to libraries in the normal way, it is very likely that everything will be fine.  However, if you are packaging mostly scripts that call utilities (without a fully qualified path), there is the potential for breakage.

Then there are systems that look up plugins at run time, etc.

Suppose, for an extreme example, that a user had installed a few things with MacPorts several years ago.  They might have ancient versions of something (installed under /opt/local) where your package relies on an up-to-date version installed in your custom prefix (say /opt/fed).  The user’s PATH may still include /opt/local/bin and friends.  As long as all of the software you are packaging avoids using PATH to find things, it should be fine.  

HTH,

Craig