What do you think about web imports like in Go or Deno, would you like to see them in Nim?
import "nimble.io/foo/bar.nim"
bar.use()
On comp time:
execCmd ("nimble get gnimble.io/foo/bar.nim")
Really like it for Deno, it's basically an command line browser, you can execute any program from the web, by just typing its address, like opening a site. And totally safe (unless you get used to typing such kind of commands in terminal, and some day accidentally type something wrong).
But without a safe runtime, like Deno, there's no much sense in that. Importing scripts from url is like playing with matches on the gas station...
Did I hurt your feelings? If yes, I'm very sorry for them.
Anyway... > But without a "safe by default" runtime, like Deno, there's no much sense doing it, too dangerous...
This is legitimate concern, but the same can be said about installing via Nimble. Or npm.
This feels like unnecessarily combining dependencies and code. If I use the same package in multiple files, and I want to update it, would I have to go through each file to do so? It just clutters up the top of my code and scatters dependencies everywhere.
Perhaps this is only useful in one-off single-file scripts, but even still adding a .nimble file is fairly simple. More personally, I’d not like running or compiling a file to install any dependencies; if I do nimble install I know it will.
Did I hurt your feelings? If yes, I'm very sorry for them.
what?
would you like to see them in Nim?
i just answered the question
The way you dismissed the idea sounded rude.
No it didn't. It sounded just fine (at least on my machine), it was a normal answer to the question.
This also makes it easier for Nimble to comprehend a package's dependencies. That being said, Nim already supports some interesting ways of establishing dependencies through Nim code itself (albeit from a different angle - Nimterop comes to mind).
Personally, I don't see much of an advantage to Go-style imports except extending the package manager to be usable on online compilers (like Nim Playground, but I suspect supporting something like this opens up security issues).
If the issue is with the friction of creating a Nimble package, you can use gists with multiple files (maybe 1 for the source and 1 for the .nimble file) as Nimble packages since gists are Git repositories.
Crazy that the grab package was created only a few weeks before this question.