1. If you were trying to use spack create https://evtgen.hepforge.org/downloads?f=EvtGen-01.07.00.tar.gz (or spack checksum, or wget, etc.) you may need to add quotation marks around the URL for Bash to not try to interpolate it. Wget worked for me when I tried this.
2. Spack has unit tests that ensure that all dependencies are actually existing packages. This is needed for the new concretizer. So either comment them out or add packages.

Flake8:

var/spack/repos/builtin/packages/evtgen/package.py:10: [E501] line too long (131 > 79 characters)
var/spack/repos/builtin/packages/evtgen/package.py:44: [W291] trailing whitespace
var/spack/repos/builtin/packages/evtgen/package.py:48: [W391] blank line at end of file

@adamjstewart Thanks for the comments!

1. Yes, the download itself works for me too, but I still have the issues: after setting

url = "https://evtgen.hepforge.org/downloads?f=EvtGen-01.07.00.tar.gz"

in the recipe, I get:

~$ spack checksum evtgen
==> Error: Couldn't detect version in: https://evtgen.hepforge.org/downloads?f=EvtGen-01.07.00.tar.gz

In addition, spack install --no-checksum evtgen fails, I think because the source tarball has the directory structure:
/EvtGen/R01-07-00/
and I'm not sure how to customize spack stage to account for the extra subir.
2. ok, added recipes for the dependencies (and updated pythia)!

plus a new one:
4. Many generators can be built with extensions for both HepMC2 and HepMC3 -- HepMC3 is actually more like a separate package than just a new version, and it can coexist with HepMC2 installs (you can do both find_package(HepMC) and find_package(HepMC3) at the same project). So I think I should actually also split the recipe for hepmc into hepmc and hepmc3?

1. Let me take a look, I know how to fix the "couldn't detect version" problem.
2. I would be fine with splitting them.

@adamjstewart thanks for fixing the url parsing so quickly. I did the hepmc split in #16892

@adamjstewart added two more packages that have dependencies here.

One more question: there is a possible circular dependency with pythia+evtgen and evtgen+pythia. (Usually what is installed is evtgen+pythia^pythia~evtgen). Should I mark it as a conflict?

@adamjstewart sounds good. I added the messages, but unfortunately it only seems to work for the case when the defaults for the variants +evtgen or +pythia8 are on. If the default is ~pythia8, then apparently spack will recurse, and fail with the error

~/repo/spack (develop *)$ spack spec -I evtgen+pythia8^pythia8+evtgen
Input spec
--------------------------------
 -   evtgen+pythia8
 -       ^pythia8+evtgen

Concretized
--------------------------------
==> Error: +pythia8 does not satisfy ~pythia8

before reaching the conflict statement, apparently. I guess this has to do with the variant forwarding that should be adressed by the new concretizer? Can you think of a better way of handling this? Otherwise I would tend to just merge the recipes as they are, even if the error message is not very informative in this case.

I’m not sure what to do about that problem, I was hoping the conflict would be hit before the recursion but I forgot that conflicts are actually evaluated after. Maybe a conflict isn’t useful then.

Yes, my preference is to merge it like this and leave the conflict messages, even if just as documentation in the code of the recipe.

Hi @adamjstewart, I still changed one of the defaults to be more sensible, but I think now this is ready to be merged.