packages
packages copied to clipboard
nim-lang
this packages list annoying
- This list doesn't solve any problem.
- Go lives a happy live without this list.
- https://godoc.org/
- waiting for CI to pass is annoying
- waiting for someone to merge the PR maybe is annoying
- dealing with broken CI is even more annoying (https://github.com/nim-lang/packages/pull/1011)
Possible Solution
Make this repository obsolete.
Why do you need to wait for inclusion in this list to use the package? If you want to do it the Go way, just nimble install https://github.com/myuser/mypackage or even git clone https://github.com/myuser/myrepo; cd myrepo; nimble develop.
The list is useful, at least, as a way to prevent package name conflicts.
* Go lives a happy live without this list.
Oh yeah? How does Go deal with package name conflicts?
You can provide a custom name for imported modules. For example import m "lib/math" lets you use math.Sin under the now different name m.Sin.
https://golang.org/ref/spec#Import_declarations
That's not what I meant... although I guess Golang allows git urls in imports so that's how it handles these conflicts.
Then what exactly do you mean with "conflicts"? And technically no, go does not "allow git urls", the details are a bit different. But it certainly does allow github urls and custom package hosting services.
Ideally this list is a temporary thing until a legitimate registry is created. At that point I'd assume publishing would have a lot less friction, but I don't know what visions there are for that.
npm also began as a git repo, and while npm has a lot of serious faults its registry probably isn't one of them.
And technically no, go does not "allow git urls", the details are a bit different. But it certainly does allow github urls and custom package hosting services.
Really? It explicitly only allows github? What if I host my package on Bitbucket/gitlab, am I screwed then?
Ideally this list is a temporary thing until a legitimate registry is created. At that point I'd assume publishing would have a lot less friction, but I don't know what visions there are for that.
Indeed. The vision is to develop a package directory, and that doesn't mean I or anyone in the core Nim team will do so, I encourage everyone to give it a go and I'm happy to integrate as many package directories as requested into Nimble.
Really? It explicitly only allows github? What if I host my package on Bitbucket/gitlab, am I screwed then?
I never said it only allows github.
https://golang.org/cmd/go/#hdr-Remote_import_paths
See https://github.com/nim-lang/packages/issues/777#issuecomment-562863060
I don't find it annoying. It is easy and anyone can understand it, even the newest newbies.
waiting for CI to pass is annoying waiting for someone to merge the PR maybe is annoying dealing with broken CI is even more annoying (#1011)
Additionally, these points are maybe annoying if you really need the package published right now.
However, why would you need to do that? You can install your library locally with nimble install.
You can also do something like nimble install https://github.com/myuser/mypackage.
I think the points made in the aforementioned comment are much more convincing.
