[lsst-dm-stack-users] Information and good practices about rules which define if a package has to managed by eups or by the system.

[Kian-Tat Lim]

Mario,

> LSST-written code will be packaged and distributed with EUPS. Some less
> common external packages may be packaged and distributed that way as
> well. But common external packages (python, numpy, Java, etc.), won't;
> we will require the user to provide them. However, since this may be
> hard for an average user (as well as for us, when we deploy to machines
> we don't fully control (think XSEDE or OSG)), we should strive to
> provide EUPS-packaged versions of those external packages as well.
> 
> Importantly, LSST packages wouldn't explicitly depend on these (i.e.,
> through setupRequired/setupOptional). Instead, the check for their
> compatibility and/or existence would be made in newinstall.sh.

	I don't think newinstall.sh is a scalable solution; I'd like
another way to do this, even if stub packages are not the right way.
Different "top-level" packages will have different system dependencies;
we shouldn't force Qserv to install matplotlib if it never uses it, or
force an lsst_apps user to install Java.  The only things that should be
in newinstall.sh are those necessary to run eups itself.  Everything
else should be modularized and will likely have to be in eups
dependencies of some kind.

	I think that may be what you mean by this:
> I see your point about newinstall.sh. What you're saying is that
> different prerequisites may be requried for different pieces of the
> stack. A quick-and-dirty workaround would be to advise user they don't
> require Java unless they're trying to install qserv. But that's not a
> good long-term solution; we should think about what needs to be done
> with EUPS to make it more aware of system packages.

-- 
Kian-Tat Lim, LSST Data Management, ktl at slac.stanford.edu