-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nimble has a number of show-stopper issues preventing us from using it. #383
Comments
Nimble would also need some sort of virtual environments, to avoid clashes between global dependencies pointing at the same package at different versions. The NIMBLE_DIR env var would need to be set to the virtual env's ".nimble" package repo dir, for the Nim compiler to find them. This might also be required by lockfile support. |
The global cache can store multiple versions of the same package and the lockfile specifies which version should be used by your particular project. While the lockfile is usually kept in Git, there is also a user-specific The lockfile can also specify local relative paths for certain packages. This usage is intended when your repo contains the packages in-tree or in submodules. |
From what I remember, the Nim compiler adds all subdirectories in NIMBLE_DIR/pkgs (defaults to ~/.nimble/pkgs) to its import path, so the first foobar-x.y.z to appear in there is the first one used by a package without lockfiles. That's a problem. |
We'll look into this. Perhaps |
eventually:
generally the global cache is a red herring - there's nothing about it that really matters in today's world. a sane starting point would be to remove it completely and maybe add it back if it's ever actually needed (ie compare to git), for an overall simplification |
@arnetheduck, I wouldn't classify any of your points as showstoppers - they don't prevent us from switching to Nimble. Few of the items can be addressed directly in Nim (more You have personal opinions and preferences regarding the global cache, but I think we can agree that the presence of a global cache does not prevent us from using Nimble. We can use the rough consensus criteria to move forward. |
Better article on rough consensus: |
the cache, as it's implemented today, can't be used - it has to go away or be replaced by something that is indistinguishable from it not being there, turning it into a cache in the true sense: if you remove a cache, the system continues functioning without any observable differences. Removing it from nimble is simply a practical way of ensuring that this is really the case, and given the quality of implementation, likely a prudent one as well because it guarantees there are no "leaks" - but how that goal is reached doesn't really matter. most crucially,
... or just keep using the Makefiles + submodules which also solve this problem, better than Nix from a cross-platform perspective. Crucially, the Makefiles already build dependencies so we can't replace Makefiles with nimble without that feature covered somehow. The other points are really trivially basic stuff that PM's offer and that we've discussed in the past as limitations to us being able to maintain a sane workflow and at the same time make our code available for the community to enjoy (eg monorepo) |
I've outlined how the cache is going to work. I don't see any problem with binary packages used in nimble-initiated builds. Nimble will select the correct package path derived from the contents of the Lockfile and the binary will be launched from there. For user convenience, a command like It's a bit of an overstatement to say that the Makefiles are currently used to manage the build dependencies. We are still installing in a manual way things like RocksDB, PCRE, Go, etc. I'm not quite sure we are using the Makefiles for actual C builds at the moment. Our dependencies on libraries like Milagro are handled though the limited In any case, it's quite different experience to run a script from time to time to install dependencies than to pay the price in terms of reduced convenience when using git submodules all the time. The submodules/makefiles approach raises the cost of creating new stand-alone tools. I remember many discussions where you've pointed out that raising the cost of something is an important consideration. |
We do, for two C libraries inside nim-nat-traversal submodules. |
and for |
And as long as we are listing non-critical deficiencies, there are many for submodules/makefiles as well:
|
Makefiles and shell scripts will continue until morale improves. |
One reason I see the global cache useful and pretty crucial is the CI use case. You don't want to do full One way of "fixing" the globally installed binaries is to make them aliases like Another thing is nim ideally has to be more aware of the lockfiles, and for that instead of knowing about |
this works the same with a project/directory-local cache, no? |
+1 |
This is not a If someone looks at the current situation at some point and believes Nimble is ready for |
We need to pin our dependencies precisely through lockfiles:
nim-lang/nimble#127
Uncategorized yet:
nim-lang/nimble#542
nim-lang/nimble#543
nim-lang/nimble#495
nim-lang/nimble#589
nim-lang/nimble#432
The text was updated successfully, but these errors were encountered: