3 ms·

The module/crate path issues raise a question, why doesn't it mimic what the file system does and have / for absolute paths, and ./ for relative paths? Of cours

by Boulth 8y ago

The module/crate path issues raise a question, why doesn't it mimic what the file system does and have / for absolute paths, and ./ for relative paths? Of course it would probably be to hard to change it now in Rust but the similarity between filesystem paths is uncanny. Dhall [0] does that, additionally they allow using URL to import code. [0]: https://github.com/dhall-lang/dhall-lang/blob/master/README.md#example-configuration https://github.com/dhall-lang/dhall-lang/blob/master/README....

oconnor663 8y ago
I think the main drawback of using URLs is that you don't have a uniform way of handling versions and compatibility. It's certainly possible for a server to implement SemVer in it's URL scheme, but I think what you get with a package manager like Cargo is much more consistent.
- Boulth 8y ago
  I was mainly proposing using paths and added URLs as an interesting tidbit but if you check the Dhall Readme I linked there is an example with content integrity (sha256 checksum). As for versioning: use different URL for different version! Even simple /v1 and /v2 would work.
  - oconnor663 8y ago
    I latched onto the URL idea because it's something we're wondering about with the `peru` project today :) https://github.com/buildinspace/peru/issues/193 https://github.com/buildinspace/peru/issues/193 Totally, fetching a single version through URLs works now, even on GitHub if you use tags. The tricky part is saying "I'm using 1.0, and 1.1 just came out, so I should upgrade to that." That requires ecosystem-wide agreement that everyone's going to use SemVer, and it assumes that everything's hosted in git or similar where there's a standard way to enumerate the available versions.
    - Boulth 8y ago
      Well tags are usually perceived as immutable but one can imagine adding an info to the tag with the "next version" coordinates. For example, tag v1.0: and a text at the bottom of the message "Next-Version: v1.1". Or if one can enumerate versions/tags you could add back pointers to new versions/tags. Example, tag v1.1 with message including "Replaces-Version: v1.0".

by Boulth 8y ago

oconnor663 8y ago

I think the main drawback of using URLs is that you don't have a uniform way of handling versions and compatibility. It's certainly possible for a server to implement SemVer in it's URL scheme, but I think what you get with a package manager like Cargo is much more consistent.

Boulth 8y ago
I was mainly proposing using paths and added URLs as an interesting tidbit but if you check the Dhall Readme I linked there is an example with content integrity (sha256 checksum). As for versioning: use different URL for different version! Even simple /v1 and /v2 would work.
- oconnor663 8y ago
  I latched onto the URL idea because it's something we're wondering about with the `peru` project today :) https://github.com/buildinspace/peru/issues/193 https://github.com/buildinspace/peru/issues/193 Totally, fetching a single version through URLs works now, even on GitHub if you use tags. The tricky part is saying "I'm using 1.0, and 1.1 just came out, so I should upgrade to that." That requires ecosystem-wide agreement that everyone's going to use SemVer, and it assumes that everything's hosted in git or similar where there's a standard way to enumerate the available versions.
  - Boulth 8y ago
    Well tags are usually perceived as immutable but one can imagine adding an info to the tag with the "next version" coordinates. For example, tag v1.0: and a text at the bottom of the message "Next-Version: v1.1". Or if one can enumerate versions/tags you could add back pointers to new versions/tags. Example, tag v1.1 with message including "Replaces-Version: v1.0".