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

Versioning #28

Open
gaborcsardi opened this issue Jul 15, 2014 · 4 comments
Open

Versioning #28

gaborcsardi opened this issue Jul 15, 2014 · 4 comments

Comments

@gaborcsardi
Copy link

Would be probably required before supporting #23, upgrades, I guess. It would be great to support semantic versioning.

(Btw. it would also be great to have versioned dependencies, but I don't want to rush forward.....)

@klmr
Copy link
Owner

klmr commented Jul 15, 2014

I think I’m going to bake this into #23. Versioning is really a distinct problem from modules per se, and fits with the packaging mechanism. I’d like to keep these things separate: modules are source files. Packaging (however implemented) tracks meta-information about modules.

@klmr klmr added this to the Support infrastructure for modules milestone Jul 15, 2014
@gaborcsardi
Copy link
Author

Sure, that makes a lot sense. So #23 essentially means a packaging mechanism, which would be just great to have!

Imho packaging is where Python is not so strong. This is the reason for the many "third-party" solutions like easy_insall, pip, conda, etc. I think npm is doing much better when it comes to distribution and packaging.

@mlell
Copy link

mlell commented Oct 22, 2021

Could it be enough to handle this as git submodules? That would delegate the task of updating, leaving just the task on how to define and satisfy the dependencies of a module.

But that would require every module to be in its own directory, i.e. each module that is installable this way must have an init.R file.

@klmr
Copy link
Owner

klmr commented Mar 30, 2022

We presumably want to use (something like) Pubgrub to resolve dependencies, which means supporting that versioning format. Alternatively, (vendored) libsolv.

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

3 participants