Details
-
Type:
Story
-
Status: To Do
-
Resolution: Unresolved
-
Fix Version/s: None
-
Component/s: eups
-
Labels:None
-
Team:SQuaRE
Description
sims_maf_contrib is a github repo we encourage people to use for general (non-LSST) contributions to sims_maf.
as such, it's git cloned and then usually put into something like ~/lsstRepos/sims_maf_contrib
(vs. ~/lsst/ .. etc for eups distributed packages).
After it's cloned, doing :
cd ~/lsstRepos/sims_maf_contrib
|
eups declare -r . -c
|
results in a nonsense path being stored in eups.
Example:
[lucy:~/lsstRepos/sims_maf_contrib] lynnej% pwd
|
/Users/lynnej/lsstRepos/sims_maf_contrib
|
[lucy:~/lsstRepos/sims_maf_contrib] lynnej% eups list sims_maf_contrib
|
eups list: Unable to find product sims_maf_contrib
|
[lucy:~/lsstRepos/sims_maf_contrib] lynnej% eups declare -r . -c
|
[lucy:~/lsstRepos/sims_maf_contrib] lynnej% setup sims_maf_contrib
|
setup: Table file not found for sims_maf_contrib tag:current (DarwinX86): /Users/lynnej/lsst/epos/sims_maf_contrib/ups/sims_maf_contrib.table
|
What does seem to work is using the tag '$USER':
[lucy:~/lsstRepos/sims_maf_contrib] lynnej% eups undeclare sims_maf_contrib
|
[lucy:~/lsstRepos/sims_maf_contrib] lynnej% eups declare -r . -t $USER
|
Warning: path /Users/lynnej/lsstRepos/sims_maf_contrib is absolute, not relative to EUPS_PATH
|
[lucy:~/lsstRepos/sims_maf_contrib] lynnej% setup sims_maf_contrib -t $USER -t sims
|
[lucy:~/lsstRepos/sims_maf_contrib] lynnej%
|
I think this is a bug. I'm not entirely sure who to assign it to, so I've started with SQuaRE.
Attachments
Activity
It seems like a bug to me (the path is mangled .. that can't be intentional can it? I suppose it could have some reason I don't know about).
Anyway, thanks for the pointer - I'll go make an issue on github.
Hmm. Do you by any chance have a directory named "/Users/lynnej/lsst", and is that in your EUPS_PATH? I think there's a bug here.
Wow, I am impressed to see this brought up.
I have no idea if this is still a bug .. I only use the -t $USER tag for this purpose now.
I think -c (and "current" explicitly) is kind of special and not just like other tags. This also happened recently with an attempt to use eups tags --clone to create a "current" tag.
If you think this is a bug, it should almost certainly be filed as a GitHub issue against eups at https://github.com/RobertLuptonTheGood/eups.