The first release candidate of Nim 1.6.0 is available for download from our nightly builds:
If you use choosenim, this should be available with choosenim #version-1-6.
This version comes with new Nimble (with support for lockfiles, see more here), so please report if you encounter any Nimble-related bugs.
Also, if there are any regressions, please let us know.
After switching to devel, my first nimble command (nimble test to be precise) showed me this error :
Error: You are working with an old version of Nimble cache repository.
Hint: Please delete your "/home/rcaillaud/.nimble" directory.
Except the folder it asks to delete contains the symbolic link to choosenim, `` nimble`` . Granted I can manually redo these links, it's still not ideal to asks the user to delete the repository that is in your $PATH to find nim, choosenim, nimble etc.
choosenim '#version-1-6' installation fails with
Building C sources
Building koch
Exception: Execution failed with exit code 1
... Command: ./bin/nim c koch
... Output: /home/test/.choosenim/toolchains/nim-#version-1-6/config/nim.cfg(16, 1) Error: invalid command line option: '--hint'
Cleaning failed build
Error: Build failed
Since updating, I've also found that nimble develop for local package will not function properly if you haven't done nimble install first (which I don't think was the case before).
How the package develop mode is working is entirely changed. Please look at the documentation for reference.
After switching to devel, my first nimble command (nimble test to be precise) showed me this error :
The reason for this is that the structure of the packages cache is changed in order to support the new package develop mode and lock files. I admit that this is inconvenient, but if you don't want to delete the entire directory you can simply delete the nimbledata.json file, pkgs directory, and the links to binary packages from the bin directory.
but if you don't want to delete the entire directory you can simply delete the nimbledata.json file, pkgs directory, and the links to binary packages from the bin directory.
You should also be able to run choosenim <ver> to restore the links after you delete the .nimble folder.
I find very useful the nimble develop command and it is not clear to me if the new version is able to provide the same functionality.
In the old documentation:
The develop command allows you to link an existing copy of a package into your installation directory. This is so that when developing a package you don't need to keep reinstalling it for every single change.
$ cd ~/projects/jester
$ nimble develop
Any packages depending on jester will now use the code in ~/projects/jester.
New documentation:
The develop command is used for putting packages in a development mode. When executed with a list of packages it clones their repository. If it is executed in a package directory it adds cloned packages to the special nimble.develop file. This is a special file which is used for holding the paths to development mode dependencies of the current directory package. It has the following structure:
[...]
It is really not clear to me what it is the purpose of the development mode and where the nimble.develop file resides (global or package specific?) and how it is used.
In particular I would be interested in understanding which (sequence of) nimble command(s) need to be the run while in a package directory (e.g. ~/projects/jester/) in order to obtain the same result (Any packages depending on jester will now use the code in ~/projects/jester.).
nimble install seems to not have changed but has a different purpose: it installs the current version of the package in the .nimble/pkgs folder. If I change the package in development other script/libraries using it as a dependency will not use the package in development but the snapshot I took when I ran the install command.
It is really not clear to me what it is the purpose of the development mode and where the nimble.develop file resides (global or package specific?) and how it is used
The develop file is package-specific and user-specific. It contains paths to packages or other develop files included in it. This allows having different development mode versions of a dependency for different packages.
In particular I would be interested in understanding which (sequence of) nimble command(s) need to be the run while in a package directory (e.g. ~/projects/jester/) in order to obtain the same result
If you want to have ~/projects/jester as a dependency you have to go to the package directory to which it is a dependency and execute nimble develop -a:~/projects/jester. This will create a nimble.develop file in the package's directory. Alternatively, you can add the dependency to another "free" develop file and include it in your project's develop file.
See develop command options in the documentation for more details.
You should also be able to run choosenim <ver> to restore the links after you delete the .nimble folder.
On Linux, default choosenim installation (at least it is for me) is $HOME/.nimble/bin/choosenim , so deleting the $HOME/.nimble/ folder delete choosenim; but yes this is what I did, I just had to re-install choosenim as well.
Isn't running nimble install once then nimble develop equivalent to the "old" nimble develop ?
It is not equivalent. There is no equivalent of the old nimble develop. Now the develop mode dependency packages are per project. There are no global development mode packages.
What nimble develop is going a way? It's is like the best thing about nimble. How do I develop 20+ packages all related in some way?
nimble develop is not going away. It is enhanced with new features that precisely try to make it more practical to work with a large number of develop mode packages as I explained here. Besides the new develop files, there is also the new nimble sync command which can enables a team of developers to coordinate their work when working with develop mode packages with a similar level of determinism that git submodules can provide.
I often test my own packages in a separate files that are not part of any project - for various examples, while trying to cleanly debug things and so on. If I understand correctly, new develop mode is fundamentally unable to support this workflow without creating a new project and running everything via nimble. Or I have to symlink my packages to ~/.nimble.
You can surely continue to work exactly as you did before. In fact, the new Nimble aims to break the dependency on Nimble when you interact with your project from the command-line or within your IDE. Nimble is responsible only for the creation of a nim.cfg file that points to the correct location of the installed packages with the standard --path: option of the compiler (this is done by running nimble setup once within your project). You can manually add additional paths at will and then gradually transition them to develop mode packages and finally published packages.
Breaking this dependency is quite valuable because now you can rely on your IDE to call nim check or nimsuggest without worrying that it will select the wrong version of some of your dependencies.
If it is executed in a package directory it adds cloned packages to the special nimble.develop file. This is a special file which is used for holding the paths to development mode dependencies of the current directory package. It has the following structure:
From https://github.com/nim-lang/nimble#nimble-develop by @bobeff
There is no equivalent of the old nimble develop. Now the develop mode dependency packages are per project. There are no global development mode packages.
From https://forum.nim-lang.org/t/8404#54212 by @bobeff
The major difference is that the new develop mode has its effects restricted to specific projects. You can have different overrides in different projects (or groups of projects) specified by a nimble.develop placed in the project directory. The rationale for this is that the old develop mode was too polluting.
To some extent, simulating the old develop mode is also quite possible. You can create one global nimble.develop file and then define some command aliases that manipulate it and include it automatically in your projects.
From https://forum.nim-lang.org/t/8404#54497 (emphasis mine) by @zahary
nimble develop is not going away. It is enhanced with new features that precisely try to make it more practical to work with a large number of develop mode packages ...
From https://forum.nim-lang.org/t/8404#54514 by @zahary
Can this just be explained from the scratch - is that change breaking because "There is no equivalent of the old nimble develop.", or it is "not going away. It is enhanced with new features"?
If there is no alternative to old nimble develop then how is it possible to "continue to work exactly as you did before."
Nimble is responsible only for the creation of a nim.cfg file that points to the correct location of the installed packages with the standard --path: option of the compiler (this is done by running nimble setup once within your project).
From https://forum.nim-lang.org/t/8404#54514
The nimble setup command creates a nimble.paths file containing file system paths to the dependencies. It also includes the paths file in the config.nims file (by creating it if it does not already exist) to make them available for the compiler.
From https://github.com/nim-lang/nimble#nimble-setup
Yes, but again, this requires setting up a project for every single script that I might want to run. If I understand correctly this means I cannot use nim c for anything without first setting up a project. Is my understanding correct?
Seems like 1.6 will be shipped with previous version of nimble https://github.com/nim-lang/Nim/pull/18872
We rolled it back for the time being but ideally 1.6 will ship with a new Nimble where we sorted out its ... teething troubles.
My 2 cents (risking redundancy/falsehood because I don't fully know the discussion which lead to the change):
II) A backwards-compatible solution could be based on a hierarchy of .pkgs directories instead of the inclusion hierarchy of .develop files described by @zahary. More specific .pkgs directories could link unchanged packages back to the higher level, while containing the usual directories for the changed packages.
Communication issue aside, sounds like a nimble install --link that replicate the old nimble develop would solve most of the issue.
The new nimble develop sounds really appealing honestly, I think once people get used to it it will be an improvement.
I feel there is a need for better sharing.
This is our milestone plan, we want to implement the following features
We think the features should be prioritised because...
if anyone has a concrete rejection with a good explanation please tell us.
every week or two weeks, tell us the progress. need funding? tell us, need a small annoying task taken care of - let us know.
The community can probably be more help in the stdlib area, instead of the actual compiler, but that area also needs improvements - for example, we wish there was an X data structure implementation because it'd be helpful for making many programs and is a clean and fast approach.
We are missing this and that library, that mainstream programming languages have, and that use case is therefore not available in the Nim ecosystem. to have the full library is too much so let's implement a useful dependency.
You know, that way, it's an active development, the community is cheering for you, and can sometimes tackle some jobs, or do research, compare APIs from other stdlibs, write documentation or books.
I think this openness would make things more exciting, because we're already sold for the main product.
Except from the Nimble requirement, this is now up-to-date (to the best of my knowledge anyway):