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

refactor #122

Closed
wants to merge 1 commit into from
Closed

refactor #122

wants to merge 1 commit into from

Conversation

cdunn2001
Copy link
Contributor

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().

This will eventually let us read multiple .ini files.

TODO: a better implementation of `readable()`.
@dom96
Copy link
Collaborator

dom96 commented May 15, 2015

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
Copy link
Contributor Author

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
Copy link
Collaborator

dom96 commented Jun 4, 2015

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).

@dom96 dom96 closed this Jun 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants