Skip to content
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

Better git management #88

Open
dom96 opened this issue Jan 16, 2015 · 5 comments
Open

Better git management #88

dom96 opened this issue Jan 16, 2015 · 5 comments

Comments

@dom96
Copy link
Collaborator

dom96 commented Jan 16, 2015

When a package is installed at a specific git commit or branch then the repo should be cloned and Nimble should then detect that a general git package has been installed (not a standalone version). It should checkout the correct commit/branch as required for the dependencies and keep the branch at #head by default.

@oderwat
Copy link
Contributor

oderwat commented Feb 22, 2015

Is there a concept about how this is suppose to work in the future?

I mean something like having a cache location for the repositories? Currently it clones it on every run into a new temp dir if I saw that correctly?

I also don't think that nimble should go into the net on every build. Even if I have "#head" branches. I would expect to have a manual command to refresh. Maybe a mechanism which tells me that I may have outdated repositories in my cache.

@dom96
Copy link
Collaborator Author

dom96 commented Feb 22, 2015

I also don't think that nimble should go into the net on every build. Even if I have "#head" branches. I would expect to have a manual command to refresh. Maybe a mechanism which tells me that I may have outdated repositories in my cache.

That's a good idea.

@dom96
Copy link
Collaborator Author

dom96 commented Dec 23, 2016

My current rough thoughts/plans:

  • We cannot simply clone a package's repo into ~/.nimble/pkgs/pkgname-git, because the package needs to be installed. The reason for this is due to the srcDir feature: a package's source code may be inside a src directory. As an example, cloning jester into ~./nimble/pkgs/jester-git would work because jester.nim would then be available in ~/.nimble/pkgs/jester-git/jester.nim. But if the jester source code was put inside a src dir then the jester.nim file would be in ~/.nimble/pkgs/jester-git/src/jester.nim and you'd need to import it via import src/jester which is incorrect.

  • The underlying problem that this issue describes is that we don't want to constantly re-clone the dependencies. A good solution is to clone them into ~/.nimble/repos/, then install to ~/.nimble/pkgs.

  • Let's say we want to install nimble@#head, and the latest tagged version of it is 0.1.0. It shouldn't be installed into ~/.nimble/pkgs/nimble-0.1.0 but into ~/.nimble/pkgs/nimble-#head instead. Nimble will then use this installation when a package requests nimble@#head, of course after some time this installation will become outdated...

  • That's where [RFC] nimble update #169 will come in. You'll be able to update your dependencies by running nimble update (this still needs to be thought about a bit more).

@dom96
Copy link
Collaborator Author

dom96 commented Dec 23, 2016

Installing compiler@#head will now copy it into ~/.nimble/pkgs/compiler-#head :D

This means that Nimble will no longer continue to reinstall packages with a "special" version (#head or #branch or #abcd231). You can still reinstall them manually by running nimble install compiler@#head or similar. This is already much better and wasn't too difficult to implement!

@dom96
Copy link
Collaborator Author

dom96 commented Dec 25, 2016

Only thing left for this issue is to clone into ~/.nimble/repos instead of /tmp. Then reuse the clones when reinstalling the same package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants