Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: lsstsw
-
Labels:None
-
Story Points:1
-
Epic Link:
-
Team:SQuaRE
Description
I cloned lsstsw into ~/Desktop/templsstsw and cd'd into it and typed ./bin/deploy and was shocked to find it installed everything into ~/lsstsw, leaving an unsable mess: some files were in templsstsw and some in ~/lsstsw.
The short-term workaround is to manually set LSSTSW before running ./bin/deploy, but this should not be necessary; bin/deploy should either set LSSTSW or not rely on it. I don't recall this problem with earlier versions of lsstsw; I think this is a regression.
For now I updated the instructions at https://confluence.lsstcorp.org/display/LDMDG/The+LSST+Software+Build+Tool but I look forward to being able to revert that change.
Attachments
Activity
That sounds great. It should make deploying and rebuilding easier and more robust.
Russell Owen Could you give master a try and let us know?
It works for me and I think it is a big improvement in usability to not rely on the user setting LSSTSW (though it is a pity it requires such obscure bash code).
I looked through the code changes and it looked OK to me, but I'm not a bash programmer so I'm not the best person to judge.
Russell Owen Thanks – I'm going to mark this ticket as done.
I suspect the only bash specific voodoo is $BASH_SOURCE, every thing else looks like standard POSIX bourne shell. Sh is definitely biased more towards writeability than readability...
Joshua Hoblitt and I talked via HipChat and concluded that LSSTSW should be deprecated in favor of scripts autodetecting where they are. That, plus some other fixes, are on the branch that Josh will merge.
The outward behavior of ./bin/deploy will remain the same as before (i.e., you'll be able to just run ./bin/deploy after cloning).