How to update a nimble package?

Beyond updating to the specific git-hashes you want every time (or tracking #head as you do) I can't think of anything. If it's something that occurs often, maybe making a nimble-task out of it might be useful? task reinstall, "Installs this package and ensures a redownload of the

How to update a nimble package?

from what i've seen, you have to remove, and then install again...

[Advice] Ways to handle "dynamicity"

> Using nim r bleh.nim uses Nim directly which requires a C compiler Thanks, I forgot that Nim uses C compiler underneath.

[Advice] Ways to handle "dynamicity"

> If you need the Nim compiler on the machine, you do not have a portable > program. Hmm, maybe I miss something here. How having "nim compiler" is different from having "nimscript vm"? In both cases you need to have some binary, why binary containing "nimscript vm" is portable and binary conta

[Advice] Ways to handle "dynamicity"

Using `nim r bleh.nim` uses Nim directly which requires a C compiler and an established Nim environment. Using embedded Nimscript does not require this, you either ship the NimVm as a library or embedded in your program. This is the difference between using lua as a library or lua through the CL

[Advice] Ways to handle "dynamicity"

That's not nimscript and defeats the purpose so... good job. If you need the Nim compiler on the machine, you do not have a portable program. > I always disliked that unix madness Ok, sorry install it to ProgramFiles, ProgramFiles (X86), ProgramData, or %AppData%, saying it's wholly a unix

[Advice] Ways to handle "dynamicity"

> when you ship it you'd select the libraries you want in your environment by > default and ship them in a folder that installs at like > ~/.config/yourProgram/stdlib I always disliked that unix madness, splitting program into arbitrary `/etc`, `/etc/bin`, `/usr/local/bin`, `~/.config/whatewer`

[Advice] Ways to handle "dynamicity"

You can also `git clone` a specific version of Nim into /tmp or something and make NimScript aware of this its lib path.

[Advice] Ways to handle "dynamicity"

The thing is you do not need a `lib` folder along side the `src`, when you ship it you'd select the libraries you want in your environment by default and ship them in a folder that installs at like `~/.config/yourProgram/stdlib` then when the user wants to use your program they'd do `yourProgram

Explanation for SSL/TLS Error

Well, `SSL_get1_peer_certificate` only exists in OpenSSLv3. So it's likely that you somehow were compiling against OpenSSL 1.1 headers. It may be the case that you only have 1.1 installed; Nim can do either out of the box, but if you were looking for 3, but it wasn't installed, you'd get an err

[Advice] Ways to handle "dynamicity"

The compiler caches it, so other than verifying that source files haven't changed, it's just about as fast as running the cached binary directly.

Explanation for SSL/TLS Error

I think, I finally got to the point of being able to prove, that the standard library's `smtp` library is broken.

Equivalent to Rust's Command spawn/try_wait?

> I think the Chronos library also offers similar. Indeed, chronos is the successor to asynctools and implements non-blocking process handling in general - here are some examples:

Equivalent to Rust's Command spawn/try_wait?

Using asynctools + peekExitCode?

[Advice] Ways to handle "dynamicity"

would `nim r -d:release src/app.nim` on a second run without changes be as fast as `nimble build -d:release` and then `./app` ? Or is there any additional overhead with this approach? This seem to be the easiest approach for projects where relying on the availability of nim compiler is not an i

[Advice] Ways to handle "dynamicity"

There's no need for "compilation" or "executable" or "dll" for scripting language. The "executable" could be an oneline bash file with `nim -r app.nim`. And the "dll" is just a folder `/app/plugins/some_plugin.nim`. Sadly, Nim doesn't support well such use case.

[Advice] Ways to handle "dynamicity"

makes sense, I'm not there yet so I am just forethinking about future roadblocks. I can imagine a typical use case would be to distribute the binary in npm and then being able to resolve the /lib from node_modules correctly, also distributing via other package managers e.g. for linux distributio

[Advice] Ways to handle "dynamicity"

Well there's no getting away from having to ship some kind of library for NimScript. Whether this library comes shipped with your program, or gets automatically extracted from the binary on runtime however is up to you. ElegantBeefs comment there means that it is possible to build a system in n