[leaveyou]

I'm a simple man, I experiment a lot, I create a module locally and bam, straight from the beginning I have to decide where I will host this module and very often I don't want to make it public so I only keep it locally on my machine, but often I need to share my module among my several machines (laptop, mini desktop) but I still don't want to share with github publicly and it's annoying that there is no easy way to do this AFAIK. In a better world I would create a "module" in a folder, give it a symbolic name at most (like 'ShinyModule') and share it in various ways; like I could share the folder using samba, ftp, ftps, sftp, https and in the consuming side, you would just import 'ShinyModule' and have a single file per consuming module which says:

'ShinyModule' https://github.com/shinyAuthor/ShinyModule or

'ShinyModule' ../../ShinyModule or

'ShinyModule' \\something\something\ShinyModule

and if there is no 'download' description for an import, the default should be ..\ShinyModule relative to the current/importing module

[the_gipsy]

And you can do all these things smoothly with rust's cargo: use a local relative path, use a git URL, or use a published package name. It's perfect if you want to try and hack around a dependency.

It's not because the tooling is better, which also happens to be true by far, but because they didn't tie themselves down to a domain name scheme. Funny, given that go waited a long time to take a shot.

[kbolino]

Rust has a different problem: too many dead packages with desirable names on crates.io. There's a lot of derelict cruft in that shared namespace, especially for packages outside those most commonly used.