Re:Tips on how to structure your home directory (2023)
by davidhaymond on Friday April 19, 2024 @11:45AM
(#40088253)
Go already supports an indirection layer, commonly known as vanity URLs. It works by making a request to a domain owned by the project and parsing a meta tag in the response that points to the actual repository location. Of course, the problem is that few projects bother to set this up.
Re:Tips on how to structure your home directory (2023)
by bheadmaster on Friday April 19, 2024 @12:17PM
(#40088660)
Go also provides a replace directive in the go.mod file [0].
Re:Tips on how to structure your home directory (2023)
by bheadmaster on Friday April 19, 2024 @10:56AM
(#40087633)
> It's better to have an indirection layer to map the project name to the project location, like most other languages do.
Who takes care of the indirection layer when the upstream decides to switch to another hosting provider?
Re:Tips on how to structure your home directory (2023)
by codelobe on Friday April 19, 2024 @11:30AM
(#40088081)
The upstream who manages their name::location mapping?
Re:Tips on how to structure your home directory (2023)
by bheadmaster on Friday April 19, 2024 @12:16PM
(#40088650)
Please refrain from using the awkward question mark, it's condescending and rude.
What do you do if they fail to update their name::location mapping, and the language doesn't provide a way to do it yourself?
At least in Go, when that happens we can just add a `replace` statement in the go.mod file:
replace example.com/foo/bar v2.35.0 => example.org/baz/bar/v2 master
Re:Tips on how to structure your home directory (2023)
by Macha on Friday April 19, 2024 @01:43PM
(#40089811)
> ...until the project decides to switch to another hosting provider
Or decides their github username looks better with an upper case letter (https://github.com/sirupsen/logrus/issues/570). Or for people who use their real name as their github name, updating their username after marriage, divorce, gender transition or whatever.
...until the project decides to switch to another hosting provider. Which has happened more than once in the past; it used to be common to host projects in Sourceforge, for a while Google Code was common, now many projects are on GitHub, and it won't surprise me at all when another forge becomes the popular one. Individually, projects might switch between being self-hosted (in their own domain name) and hosted on a shared forge (using the forge's domain name).
IMO, it's a bad design. It forces the project's repository's location to become the project's official "name", that is, it mixes up location and naming. It's better to have an indirection layer to map the project name to the project location, like most other languages do.