problem-solving icon indicating copy to clipboard operation
problem-solving copied to clipboard

"depends" should move towards only allowing the hash form

Open ugexe opened this issue 1 year ago • 6 comments

Depends can be listed as Foo:ver<1> or {"name":"Foo","version":"1"}.

The former (Foo:ver<1>) made it easier for distribution authors to hand write their dependencies, as well as making them follow the same format as they would use in code itself. Originally you could only list the short-name, and the ability to filter on e.g. :ver<...> came much later. However it was not sufficient for representing e.g. dynamic dependencies, and so the hash form was invented by a few of us at a Perl Toolchain Summit many years ago. Another flaw of this dependency format is there is no internal parser for these strings, and even if there was it would likely not work for representing a dependency from another language (which may allow . in the name for example). Further, there are complications in regarding to escaping e.g. <.

The later ({"name":"Foo","version":"1"}) is better in most regards. Raku has to (and already does) parse JSON so the ability to parse and structure that data already exist. This would benefit code like https://github.com/rakudo/rakudo/pull/5060 as it could get rid of the fragile dependency name parsing logic and use this structured data instead. Packagers (such as for apt) that may not be as familiar with Raku can more easily understand (and more easily write tooling in non-raku languages) this format. The fact this format doesn't look like an import statement could potentially be seen as a good thing, as it might guide users more towards declaring dependencies on distributions instead of as modules (although admittedly this is a bit of a reach).

PROS

  • Looks less like an import statement, which would make switching to using only distribution names for dependencies every-so-slightly more intuitive.

  • No special parsing needed (besides json).

  • A single way of declaring depends.

CONS

  • Pretty much every distribution in every ecosystem needs to change (although the zef ecosystem could temporarily replace the non-hash forms with hash forms).

  • More verbose.

  • Can't theoretically use adverbs in provides section, i.e. "Foo:api<2>":"lib/Foo2.rakumod"

ugexe avatar Oct 30 '23 16:10 ugexe

* No special parsing needed (besides json).

We would still need to parse the Version

* A single way of declaring depends.

I think that most don't know that there are two ways of declaring depends.

JJ avatar Oct 30 '23 19:10 JJ

I like just about everything about this proposal! It has always felt weird that in a structured data format you'd still have to parse the values in a different way to get at the actual data. And the point about the string format making it hard for packagers hits quite home.

niner avatar Oct 31 '23 13:10 niner

  • Can't theoretically use adverbs in provides section, i.e. "Foo:api<2>":"lib/Foo2.rakumod"
"Foo": {
  "path": "lib/Foo2.rakumod",
  "api": 2
}

Don't know how much would it complicate handling of META6 though.

vrurg avatar Nov 06 '23 14:11 vrurg

DUB, the "package and build manager" of the Dlang, knows also "dependencies... and much more. Maybe worth a look at it's "format"?

AntonOks avatar Nov 07 '23 08:11 AntonOks

Is this Rakudo independent? Or an extension to the language specification?

https://docs.raku.org/type/Metamodel/Versioning

Also, why isn't semantic versioning used more prominently, e.g. to denote minimal depends version# ?

https://docs.raku.org/type/Version

jubilatious1 avatar Nov 29 '23 09:11 jubilatious1

The format is described in https://github.com/Raku/old-design-docs/blob/master/S22-package-format.pod

niner avatar Nov 29 '23 14:11 niner