# Stack installation can leave packages not tagged current

XMLWordPrintable

## Details

• Type: Bug
• Status: To Do
• Resolution: Unresolved
• Fix Version/s:
• Component/s:
• Labels:
• Team:
SQuaRE

## Description

I installed a clean Winter2014 on my Mac in a new directory using the standard procedure (from a fresh login; my old stack was NOT setup):

 mkdir lsst_home2 cd lsst_home2 curl -O http://sw.lsstcorp.org/eupspkg/newinstall.sh bash newinstall.sh

It completed without errors, but when I tried to setup some packages it complained that it could not find suitable versions. It turned out that many packages in my new stack were missing the "current" tag. Those packages all had one thing in common: I had a git version checked out and declared in my old stack using version name "git" and tag "rowen" (my username). Many, perhaps all, of those git packages were also tagged "current" in my old stack.

I have no idea how my new stack could have learned anything about packages declared in the old stack. The only LSST environment variables that I normally have defined are $LSST_HOME and$LSST_GIT, and I'm pretty sure I updated the former for the new stack before starting the installation.

Neither my old or new stack has a developer sandbox (since it is on my personal work computer).

My .eups/startup.py contains just one line:

 hooks.config.Eups.userTags += ["test"]

and I do not actually use that tag anymore (I always use "rowen", instead) so I should probably comment that out.

## Activity

Hide
Mario Juric added a comment -

Robert, any ideas on what could be happening? How does EUPS decide to tag something as current upon 'eups distrib install'?

Show
Mario Juric added a comment - Robert, any ideas on what could be happening? How does EUPS decide to tag something as current upon 'eups distrib install'?
Hide
Robert Lupton added a comment - - edited

If you declare a new product it's declared current — after all, it's the only option and this was the path of least surprise. User tags are in your own namespace (they are declared in ~/.eups partly because of read-only tags) and are globally visible across EUPS_PATH entries. This need not be the case, but I think it's almost always what you want.

So, if you have a tag rowen attached to product XXX and install a new version into a new stack, eups thinks that XXX already has a version so it doesn't call XXX current.

I think that this is correct behaviour. "current" is just the default default tag; the thing you get if you don't say anything else. If you say

  setup -T myTag XXX

you've replaced current by myTag. So, if you want to set current it's like any other (in this case global) tag and you should tell eups distrib install to set it.

Show
Robert Lupton added a comment - - edited If you declare a new product it's declared current — after all, it's the only option and this was the path of least surprise. User tags are in your own namespace (they are declared in ~/.eups partly because of read-only tags) and are globally visible across EUPS_PATH entries. This need not be the case, but I think it's almost always what you want. So, if you have a tag rowen attached to product XXX and install a new version into a new stack, eups thinks that XXX already has a version so it doesn't call XXX current. I think that this is correct behaviour. "current" is just the default default tag; the thing you get if you don't say anything else. If you say setup -T myTag XXX you've replaced current by myTag. So, if you want to set current it's like any other (in this case global) tag and you should tell eups distrib install to set it.
Hide
Mario Juric added a comment -

Hmm, looks a bit counterintuitive to me.

If I run eups distrib install foo -t bar, I'd expect to be able to setup it with setup foo -t bar. Analogously, if I run eups distrib install foo, I'd expect to be able to setup it with setup foo, no?

I'd argue that 'current' should be treated as just another tag, and the current behavior of eups distrib install for tags other than 'current' is to set them. Otherwise, the user (even an expert one) will be surprised by the behavior.

Show
Mario Juric added a comment - Hmm, looks a bit counterintuitive to me. If I run eups distrib install foo -t bar , I'd expect to be able to setup it with setup foo -t bar . Analogously, if I run eups distrib install foo , I'd expect to be able to setup it with setup foo , no? I'd argue that 'current' should be treated as just another tag, and the current behavior of eups distrib install for tags other than 'current' is to set them. Otherwise, the user (even an expert one) will be surprised by the behavior.
Hide
Robert Lupton added a comment -

So I have things setup so current means what I want it to mean. Then someone installs a new experimental version and it becomes current? If you want that, say eups distrib install foo -t current. If that doesn't work, it's a bug.

Show
Robert Lupton added a comment - So I have things setup so current means what I want it to mean. Then someone installs a new experimental version and it becomes current? If you want that, say eups distrib install foo -t current . If that doesn't work, it's a bug.
Hide
Mario Juric added a comment -

You're assuming that everyone is writing into the same stack, w/o coordinating on the meaning of tags?

Show
Mario Juric added a comment - You're assuming that everyone is writing into the same stack, w/o coordinating on the meaning of tags?
Hide
Robert Lupton added a comment -

Yes, that should be the default assumption. I know it's not as default as it once was (given laptops), but it's much the most efficient way to work.

So we coordinate global tags between sites, and current is indeed a sort of global tag — it's the default global tag. I do not think that we should manage what a given site thinks of as current; we do manage beta and HSC and ... and if that matters they should use setup -T beta (or make beta a default post-tag via hooks.config.Eups.defaultTags["pre"].append("beta") which essentially replaces "current" by "beta" as the default global tag

Show
Robert Lupton added a comment - Yes, that should be the default assumption. I know it's not as default as it once was (given laptops), but it's much the most efficient way to work. So we coordinate global tags between sites, and current is indeed a sort of global tag — it's the default global tag. I do not think that we should manage what a given site thinks of as current; we do manage beta and HSC and ... and if that matters they should use setup -T beta (or make beta a default post-tag via hooks.config.Eups.defaultTags ["pre"] .append("beta") which essentially replaces "current" by "beta" as the default global tag
Hide
Mario Juric added a comment -

Hmm, OK, I understand; what you're saying is that 'current' is not necessarily the default tag to be used by setup, that one can override it via hooks.config.Eups.defaultTags?

OK... Let's imagine I override the default and make 'beta' the default tag. Does that mean that eups distrib install foo will look into beta.list to find the version of product foo?

Show
Mario Juric added a comment - Hmm, OK, I understand; what you're saying is that 'current' is not necessarily the default tag to be used by setup , that one can override it via hooks.config.Eups.defaultTags ? OK... Let's imagine I override the default and make 'beta' the default tag. Does that mean that eups distrib install foo will look into beta.list to find the version of product foo ?
Hide
Tim Jenness added a comment -

Is this ticket still relevant?

Show
Tim Jenness added a comment - Is this ticket still relevant?

## People

• Assignee:
Unassigned
Reporter:
Russell Owen
Watchers:
Robert Lupton, Russell Owen, Tim Jenness