Implement --dir option to override where nimbleDir

[dom96]

For reasoning check discussion on IRC at about 6pm: http://irclogs.nim-lang.org/11-04-2015.html

[cdunn2001]

Good discussion in IRC, but not quite complete.

18:28:04 Araq nimble is not for end users of software
18:28:10 Araq it's for Nim developers

Exactly. In fact, nimble should be workspace-oriented, like Go-install. It's fine to use ~/.nimble/bin by default, but when some ENV-var is set, it should check-out and build all packages under a given workspace directory. Not only does that solve the problem of over-writing existing installations, but also it facilitates development of multiple packages in a single workspace.

If you don't use workspaces, then you'll inevitably end up with environment wrappers like virtualenv, rvm, or envirius (for Go).

A command-line flag is fine, but not the usual workflow. I don't want to type extra flags repeatedly. Usually, I want nimble to learn the workspace from either my shell (via ENV-var) or possibly from looking up a few directories for a nimble-config file. Note that using an ENV-var has a big drawback:

• http://stackoverflow.com/a/20725538/263998

So I strongly recommend letting nimble search up the directory tree (at least 0 or 1 levels) for a file called nimble.workspace. That file could define other directories which are also part of the workspace, so that system packages could be shared, if desired.

But aside from $GOPATH, what are the downsides of the Go way?

• https://github.com/golang/go/wiki/GithubCodeLayout
• https://golang.org/doc/code.html
• http://thenewstack.io/understanding-golang-packages/

[cdunn2001]

Or maybe search for nimble.ini, but look in . and .. before ~/.config/nimble.

[dom96]

Could you tell me what the problem is exactly in terms of working with Nim? If you could explain a particular problem that you are having with Nimble then I would be eternally grateful.

It seems to me that you are applying the workflow principles from other package managers, without (perhaps) having yet attempted to work with Nimble in the way that Nimble was designed to be worked with. Perhaps I am wrong, but I would like for you to give it a chance, apologies if you have already done so.

[cdunn2001]

I read the IRC discussion. There is much disagreement, but I thought there was at least some agreement that we often need a bit more flexibility than is currently offered.

nimble checks out a package into /tmp and then installs in ~/.nimble/pkg/*. That is fine for things I simply depend on, but I want to develop both my own package and the packages I depend on. So I need git to manage those dependencies. nimble needs to use my git-directories for checked-out packages.

Furthermore, I might have several "contours". While working on one package, I might need one set of versions of dependencies. For another, I need another set.

I would nimble build within a workspace, and everything will be built with my current versions. I don't need nimble to update anything I've already checked out, but it should be possible to nimble install newly discovered dependencies without updating the world.

Basically, I juggle lots of things at once. This was my normal workflow when I worked at Amazon. The package manager needs to allow this. I read the nimble docs, but maybe I have overlooked something. How should I be using this?

Even aside from this, your plan (as I understand it) could be error-prone. If you set --dir on the command-line, then you might accidentally forget that flag the next time you run it, and you could end up updating the main installation.

Go does pretty well with workspaces. How familiar are you with that system?