<div><div dir="auto">Lmod is quite neat as is the original. Thanks for the tip guys! I don’t suppose that there’s something that also covers windows? We’ve got more than one os to support. WSL isn’t universally available sadly.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 21 Aug 2019 at 10:57 am, Skylar Thompson <<a href="mailto:skylar.thompson@gmail.com">skylar.thompson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We also use Environment Modules, with a well-established hierarchy for<br>
software installs<br>
(software-name/software-version/OS/OS-version/architecture). Combined with<br>
some custom Tcl functions and common header files for our module files,<br>
this lets us keep the size of most module files very small (2-5 lines).<br>
<br>
If we were to do it again today, maybe we'd use Lmod, but Modules is<br>
functional and has a lot of inertia.<br>
<br>
On Tue, Aug 20, 2019 at 06:50:31PM +0000, Ryan Novosielski wrote:<br>
> Really sounds like you should be using environment modules. What I’d recommend to anyone starting out today would be Lmod: <a href="https://lmod.readthedocs.io/en/latest/" rel="noreferrer" target="_blank">https://lmod.readthedocs.io/en/latest/</a><br>
> <br>
> Most of the software building/installation packages interface with it.<br>
> <br>
> Generally the software installs are done into a place that’s unique for each package and version, and maybe even for what compiler it was built with (see hierarchical).<br>
> <br>
> --<br>
> ____<br>
> || \\UTGERS, |---------------------------*O*---------------------------<br>
> ||_// the State | Ryan Novosielski - <a href="mailto:novosirj@rutgers.edu" target="_blank">novosirj@rutgers.edu</a><br>
> || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus<br>
> || \\ of NJ | Office of Advanced Research Computing - MSB C630, Newark<br>
> `'<br>
> <br>
> > On Aug 20, 2019, at 1:11 PM, David Mathog <<a href="mailto:mathog@caltech.edu" target="_blank">mathog@caltech.edu</a>> wrote:<br>
> > <br>
> > On a system I am setting up there are a very large number of different software packages available. The sources live in /usr/local/src and a small number of the most commonly used ones are installed in /usr/local/bin, /usr/local/lib and so forth. The issue is that any of the target end users will only want a couple of these. If they were all fully installed into /usr/local there would be some name conflicts. They may also be bringing some of their own versions of these, and while $PATH order can help there, it would be best to avoid those possible conflicts too. Users don't have priv's to modify /usr/local, so they cannot install/uninstall there themselves.<br>
> > <br>
> > So I'm looking for something like<br>
> > <br>
> > setup software_name install<br>
> > setup software_name remove<br>
> > <br>
> > which would install/uninstall the packages (perhaps by symlinks) from<br>
> > <br>
> > /usr/local/src/software_name<br>
> > <br>
> > under the user's home directory. The goal is that the setup scripts NOT be constructed by hand. It would have a<br>
> > <br>
> > setup software_name install<br>
> > <br>
> > which would emulate a:<br>
> > <br>
> > make install<br>
> > <br>
> > and automatically translate it into the appropriate setup commands. Some of these packages have hundreds of programs, so anything manual is going to be very<br>
> > painful.<br>
> > <br>
> > Anybody seen a piece of software like this?<br>
> > <br>
> > I don't expect this to work in all cases. Some of these packages hard code paths into the binaries and/or scripts. The only hope for them is for the user to do some variant of:<br>
> > <br>
> > cd $HOMEDIR<br>
> > (cd /usr/local/src; tar -cf - software_name) | tar -xf -<br>
> > cd software_name<br>
> > make clean #pray that it gets everything!!!<br>
> > ./configure --prefix=$HOMEDIR<br>
> > make<br>
> > make install<br>
> > <br>
> > There is a file which documents how to build each package, although it is nowhere near complete at this time.<br>
> > <br>
> > Docker is already available if the user wants to go that route, which avoids this whole issue, but at the cost of moving big images around.<br>
> > <br>
> > Thanks,<br>
> > <br>
> > David Mathog<br>
> > <a href="mailto:mathog@caltech.edu" target="_blank">mathog@caltech.edu</a><br>
> > Manager, Sequence Analysis Facility, Biology Division, Caltech<br>
> > _______________________________________________<br>
> > Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
> > To change your subscription (digest mode or unsubscribe) visit <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br>
> <br>
> _______________________________________________<br>
> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
> To change your subscription (digest mode or unsubscribe) visit <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br>
<br>
-- <br>
Skylar<br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="https://beowulf.org/cgi-bin/mailman/listinfo/beowulf" rel="noreferrer" target="_blank">https://beowulf.org/cgi-bin/mailman/listinfo/beowulf</a><br>
</blockquote></div></div>