i think the Version part is what i would also like to see in Spack #1814, but I think it would also make sense to have access to os through classes which are already in Spack. The problem with re-using Spack here is that you need spec, i.e. spec.architecture.platform_os.version.

Even though Spack may not have the same granularity in OS's (Redhat vs rhel /centos), i think it would still save you some lines of code here.

Yeah, I wanted to use those. But I don't think it's documented, so I don't know what all of the options are or what possible values they return (if someone wants to do this that would be fantastic). And a lot of those return the same things as platform.* anyway. They're just wrappers, like how join_path is just a copy of os.path.join. So the lines of code are the same and the results are mostly the same. There might be different results for things like BGQ or Cray, but it's not documented and I can't test it. And like you said, you need the spec, which isn't necessarily available outside of install().

@adamjstewart: they're wrappers if you assume that the build host is where you'll actually run. The difference is that they're attributes on the spec, which might be a spec for some other architecture (e.g. backend nodes on BG/Q or Cray). So making a Python call isn't always going to give you the same thing as checking an attribute on a spec. But yes, they need documentation otherwise i can't really expect people to use them.

That's a good explanation. Yeah, I can use them as soon as they get documented. Aside from that, how do people feel about this strategy? It's kind of a pain in the ass for packages with as many downloads as allinea-forge, but it's really not that bad for other packages that provide a different version for Linux and Mac. Compilers are usually inbetween, and since those are usually downloaded manually, we don't even have to worry about url_for_version().

since you only need to have different url's and hashes, maybe in addition to url_for_version there could be hash_for_version? Both should have access to spec, which would not be the case if we were talking about depends_on.

So, I think we clearly need conditional logic for this, and what you're doing here will work right now. But if it turns out that you need a separate tarball for a backend arch, this won't work.

I think version needs a when clause like the other directives, where you could put when='platform=darwin' or when='platform=centos.*'.

I would probably initially make the when on version only support, e.g., platform and os, as if you make it allow other things, picking a version during concretization can get complicated (it starts depending on more things and you have to iterate). But some future concretizer could handle that.

Thoughts?

I think adding when support to version() would make a lot of sense. It would just need to support everything I did in this PR, including os, distro, os-version, and arch. I can't think of a need for it to have full access to the spec aside from that.

This currently crashes on macOS because the mirror logic tries to parse the extension but .dmg is invalid. Honestly I'm not sure if it should be valid. I don't think Spack can install a .dmg file so I guess the package just shouldn't support macOS.

@adamjstewart : is there any reason not to use allinea-forge template provided in this ticket? It's better (more reliable/robust) than current package.py.

The problem is that every single unit test fails:

InstallError: No download available for 'Linux', 'debian', 'wheezy/sid', 'x86_64'

This solution is not very robust. We need to add a when= directive to version(). We also need to allow packages to exist that have no available versions (at least for the current arch).

Oh ok, I saw the tests now.

Closing as this discussion ended a long time ago.