Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc issue about develop support #185

Open
albestro opened this issue Apr 19, 2024 · 1 comment
Open

doc issue about develop support #185

albestro opened this issue Apr 19, 2024 · 1 comment

Comments

@albestro
Copy link
Contributor

The `--develop` option currently handles the following the following:
* `spack env --with-view <name>` requires an argument.
* v0.20 and earlier did not accept a named argument to `spack env --with-view`, instead requiring the presence of a view named `default`.
* v0.21 requires the name of the view be passed as a positional argument.
* if `--develop` is passed, or `v0.21` is detected.
* will be removed when v0.21 is the oldest supported version of Spack.

In addition to the repeated "the following", IMHO the bullet points list is not straightforward to understand. Some doubts I have:

  • it probably refers to spack env activate --with-view <name> and not spack env --with-view
  • first point: I would specify that the second part of the sentence refers to the environment configuration
  • second point: are you referring to <name> with "positional argument"?
  • third point sounds like a bit unlinked. I think doc meant that --with-view <name> applies starting from 0.21 (and so also develop included). right?
  • fourth point: are you referring to --develop? in case, I might argue that it would be beneficial to keep it there for a while. Two arguments in support of this argument:
    • what if you remove it and then you have to re-add a develop option because another similar workaround is needed?
    • develop sounds general enough, so it applies to all possible workarounds needed. otherwise we might end up having different flags for different workarounds of this kind and drop just the ones not used anymore

I really hope that spack will allows us to completely forget about this option sooner rather than later.

@RMeli
Copy link
Member

RMeli commented Apr 19, 2024

I agree that this could be better explained.

second point: are you referring to with "positional argument"?

This is how I interpret it.

third point sounds like a bit unlinked. I think doc meant that --with-view <name> applies starting from 0.21 (and so also develop included). right?

I think the doc is describing #164. The spack_version is defined here

def spack_version(self):
# determine the "major" version, if it can be inferred.
# one of "0.20", "0.21", "develop" or "unknown".
commit = self.config["spack"]["commit"]
if commit is None or commit == "develop":
return "develop"
# currently supported
if commit.find("0.20") >= 0:
return "0.20"
# currently supported
if commit.find("0.21") >= 0:
return "0.21"
# branches that contain wip for the next v0.22 release
if commit.find("0.22") >= 0:
return "0.22"
return "unknown"

So if you are not using 0.20 or 0.21, develop or unknown is returned.

The string comparison in #164 looks dangerous (it evaluates to True with both develop and unknown) and should be fixed, but what the doc is likely trying to convey is that if you are not using a specific version it's up to the user to trigger the condition with --develop.

fourth point: are you referring to --develop?

It should only refer to the specific spack env activate --with-view <name> workaround (see #152 for the removal of an old workaround, when it became unnecessary). --develop will need to stay around until 1.x, I think.

I don't recall if it's clearly stated in the documentation, but the idea is to support the last two minor versions of Spack, plus develop. So right now we should be able to work with v0.20, v0.21 and develop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants