[Info]: What are the reasons behind a customizable version-regexp

[meedstrom]

I'm wary of starting a discussion about design choices where smart people have probably spent a lot of time thinking about them, so I just want to ask someone for a quick answer, or it would be great if someone can point me to past discussions, which I could not find on this issue tracker nor on that of Melpa.

Background:

• The :version-regexp allows substitution with %p and most recently %v.

  • (Examples can be seen in https://github.com/melpa/melpa/commit/f9103b6c58996e75c0e5c23fc0fb12afd65424c0 and the substitution is done by the function package-build--version-regexp at https://github.com/melpa/package-build/blob/master/package-build.el)
• I see the ergonomics of it, but also observe that this would not be needed, if devs could not configure the regexp anyway.
• From the perspective of people writing a downstream package manager, this is not really making tags-as-versions look nice and simple, compared to the Package-Version header. Needing a regexp at all is already one level of complication, making it user-customizable and unique per package adds another level, and then having this regexp potentially be composed of two parts to be merged with code is another level again.

If I were to try to answer this myself, I'd guess that it is historical reasons from when Melpa Stable was just being rolled out and wanted to add as many packages as possible. I guess another reason might be to filter out tags that the author does not intend to be version strings, but I don't think of this as an unfixable issue from the author's perspective.

[milkypostman]

I'd guess that it is historical reasons from when Melpa Stable was just being rolled out and wanted to add as many packages as possible

Yup

[purcell]

Needing a regexp at all is already one level of complication, making it user-customizable and unique per package adds another level

There's a default which almost always works.

I'd guess that it is historical reasons from when Melpa Stable was just being rolled out and wanted to add as many packages as possible.

And also that some elisp packages are hosted in bigger non-elisp repositories that have all sorts of tag naming conventions dating back many years.

[meedstrom]

Thanks for your responses!

The reason I wanted to know, is that there are at least two new package managers that will do version checking that is aware of tags. One is Elpaca, and another may be the Emacs 30 or 31 use-package :vc, going by current discussions on emacs-devel.

Problems I foresee:

• Both are unlikely to adopt package-build--version-regexp, so recipes with %p or %v may cause an apparent version mismatch when an user installs a package.

• I don't know how use-package :vc will work exactly, but I won't be surprised if it turns out that users who coopt it into a "new Straight/Elpaca/Quelpa" and use auto-fetched recipes from Melpa, will have to drop the :version-regexp altogether from the Melpa recipe, if :vc will not support a custom value.

You could consider it out of scope for Melpa to worry about this, but might it make sense when the dust settles to gently ping authors who use tags that would not match whatever version-regexp Emacs 30/31 settles on? (I can do it for you.)

If you agree, then a separate thing that can already be done is to say that new recipes submitted to Melpa may not specify a custom regexp henceforth. Just an idea, but from your responses, it seems we are not going to discover new big non-elisp repositories that have all sorts of tag naming conventions dating back many years ;)

[purcell]

These seem to be very speculative concerns that other people planning future work might make different choices from us, plus ideas about how we could mitigate that. Ultimately MELPA exists to build and host installable packages, and it's a secondary concern whether the recipes and build machinery are useful to anyone else.

We're generally just doing what works for us across almost 6000 packages since 2012. If someone wants to reinvent what MELPA does without reusing it, they will eventually hit the same issues we did and either learn from what we did or invent something incompatible. I've seen more of the latter than the former, particularly from the core/ELPA folks, so I don't see a productive role for us in this discussion.

---

Couple of concrete points nonetheless:

%v is apparently just a shorthand for a longer regexp pattern, which makes sense to me, so that would easily by handled by whatever hypothetical package managers you're worried about.

I probably wouldn't have added %p to package-build myself, but no MELPA recipes actually use it, so this is all a bit moot. @tarsius might have a good reason for %p though. If not, we can just remove it.

---

I'll go ahead and close the ticket because I think we've answered the headline question, but feel free to comment further.

[meedstrom]

Thank you for your time.

[purcell]

^ Apologies if a little saltiness is showing. I'm happy that some other package installers have found it helpful to use our recipes etc., but all the Non-GNU ELPA and package-vc machinery has tended to reinvent those and MELPA in new and incompatible ways, and I've personally found that a little frustrating. :)