refactor

[cdunn2001]

This will eventually let us read multiple .ini files. Why? Because I also want to let the .ini define the URL for the origin of nimbledata.json. Then, that file can define a contour of a workspace. That would allow me to modify several open-source packages while I work on my own packages which use them. That way, nimble can support a workspace-based development model, something which Go build tools do well. (See #114 .)

TODO: a better implementation of readable().

[dom96]

Why have multiple Nimble configuration files? How will Nimble find them?

I think that I am only half aware of the way you are intending on using Nimble to develop your packages.

Do you want Nimble to be aware of Nimble packages on your system which you have downloaded yourself (via git or otherwise)?

[cdunn2001]

Please look into Go. There is much to learn from its build system. Go-install unfortunately mixes system-wide installation (into GOROOT) with workspace development (GOPATH), but it does each well.

Yes, I want to use Nimble to develop multiple packages, including dependencies. I find bugs in dependent packages quite often. This is especially true for a new language like Nim. So I want:

1. a contour of packages in a workspace (i.e. a consistent set of branches or versions)
2. some of those packages to come from my own Git forks (even if they are "official" packages in the nim-lang GitHub organization)
3. multiple workspaces.

The users of Nimble are themselves software developers who need to be able to modify dependencies and use their modified versions until/unless their patches are accepted.

I like the simplicity of Nimble. I'm just looking for flexible workspace support.

[dom96]

Sorry, but I don't see a need for multiple Nimble configuration files. I think that will make things unnecessarily complex.

You can easily develop dependencies by cloning their repos yourself, working on them locally and installing them via nimble if necessary (by running nimble install in the package's directory).