py-metomi-isodatetime: fix url parsing

[adamjstewart]

Closes #41414

Could have modified our regexes to better support this version identifier but this is literally the only case we have in Spack as far as I know so will wait until this is more common.

[climbfuji]

Thanks @adamjstewart. I tried your PR (cherry-picked your commit), but still getting:

[cylctest-20231204] heinzell@JCSDA-L-18146:~/work/spack-stack/spack-stack-cylc8 [brew-arch64]> spack checksum py-metomi-isodatetime@3.0.0
==> Error: Couldn't detect version in: https://files.pythonhosted.org/packages/source/m/metomi-isodatetime/metomi-isodatetime-1!3.0.0.tar.gz
[cylctest-20231204] heinzell@JCSDA-L-18146:~/work/spack-stack/spack-stack-cylc8 [brew-arch64]> spack checksum py-metomi-isodatetime@3.1.0
==> Error: Couldn't detect version in: https://files.pythonhosted.org/packages/source/m/metomi-isodatetime/metomi-isodatetime-1!3.0.0.tar.gz

Am I doing something wrong?

[tldahlgren]

Confirmed the package's version sha256 are still valid with the change. Just a simple question.

[climbfuji]

@tldahlgren This is unfortunately not working for me, but it's likely that it is a user error.

[tldahlgren]

@tldahlgren This is unfortunately not working for me, but it's likely that it is a user error.

Which part? The PR or the use of an f-string?

[climbfuji]

@tldahlgren This is unfortunately not working for me, but it's likely that it is a user error.

Which part? The PR or the use of an f-string?

The PR itself (sorry for not being clear)

[adamjstewart]

I didn't fix:

> spack checksum py-metomi-isodatetime

I did fix:

> spack checksum py-metomi-isodatetime 3.1.0

The former is a completely different set of Spack code. I can fix it if you want, but will need to find time to adjust the regexes to add support for this.

[adamjstewart]

Ah, apparently my solution only works for versions that have already been checksummed. Will need to adjust the regex instead.

[adamjstewart]

We need to decide whether or not we care about the epoch number in https://peps.python.org/pep-0440/#public-version-identifiers. Like, should the version be called 1!3.0.0 or 3.0.0? The epoch is designed for when a package changes from something like 2022.11.12 to 1.2.3. Normally, the former would sort as newer than the latter, but the epoch allows you to correctly sort these.

[becker33]

A few core Spack developers discussed this today. Our proposal is to model the epoch in the same manner that Python does (and Fedora as well). We will propose a PR with the N!A.B.C version syntax supported. Versions without an epoch will have an implicit 0 epoch. Infinite versions (develop, main, etc) will have an implicit infinite epoch so they always remain "greater than" every other version.

[climbfuji]

A few core Spack developers discussed this today. Our proposal is to model the epoch in the same manner that Python does (and Fedora as well). We will propose a PR with the N!A.B.C version syntax supported. Versions without an epoch will have an implicit 0 epoch. Infinite versions (develop, main, etc) will have an implicit infinite epoch so they always remain "greater than" every other version.

That sounds great, thanks for following up @becker33 !

[adamjstewart]

To me, this seems like it should be much lower priority (only affects 1 package) than supporting a/b/rc/dev as being less than stable (affects most packages).

[becker33]

@adamjstewart while I agree about impact, I think it's much easier to support than the more important issue around pre-release versions.

[LydDeb]

For information purposes, after scanning all 500644 packages present on Pypi, I identified 40 which appear to be concerned by the Epoch segment (the character "!" is present in an URL of a release).

[adamjstewart]

That's impressive work. So only 0.008% of packages.

[LydDeb]

It was a bit long. The python modules xmlrpc.client and requests were very useful for listing all the packages and retrieving useful information.
What is the final decision regarding support for Epoch versioning syntax?

[adamjstewart]

Should we merge this as is? It doesn't fix:

> spack checksum py-metomi-isodatetime

but it does fix:

> spack fetch py-metomi-isodate

The latter is much more important.

[LydDeb]

I think we can keep this modification which allows the installation of the package. We could possibly add a comment indicating that the checksum does not work.

[climbfuji]

I concur, a note that the checksum feature doesn't work for this package would be nice.