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.

Sign up for GitHub

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

Jump to bottom

Enable :version to refer to sub-modules version and not the version of the currently building project #29

Open
alexdforeman opened this issue Jun 5, 2015 · 5 comments
Open

Enable :version to refer to sub-modules version and not the version of the currently building project #29

alexdforeman opened this issue Jun 5, 2015 · 5 comments

Comments

@alexdforeman
Copy link

Currently :version in dependency versioning refers to the current sub-module's version, which is fine when all submodules are in sync with each other.

In a world where subprojects have differnt versions however this breaks.

It would be really nice that if lein-modules sees a :version it tries to find that project in its source tree and substitutes that version in and then if it cant find it then falls back to the modules version by default.

This should be 100% compatible with what is happening currently, however it would also enable clever version tracking of submodule dependencies which are not all the same.
@jcrossley3
Copy link
Owner

Good idea, thanks! I'll try to look into this soon.

jcrossley3 added a commit that referenced this issue Jun 9, 2015
@jcrossley3
Discover child module versions automatically #29
1578dd1 
This involved quite a bit of refactoring of the progeny stuff into
common so that versionization could use it, too. It looks for the
top-most project and then all of that project's children. This can lead
to an infinite loop when middleware is invoked so we introduce some
macros to disable middleware when parents and children are being read.

Unfortunately, discovering all the children can add quite a bit of time
to the build, almost double for some of the tasks in the Immutant build.

Parking on a branch for now.
@jcrossley3
Copy link
Owner

Alex, you can install that #29 branch locally just to see if it addresses your needs, but I'm hesitant to release it as it impacts performance quite a bit.

@alexdforeman
Copy link
Author

Thanks Jim, Ill either test it today or first thing tomorrow and get back to you ASAP

@alexdforeman
Copy link
Author

Jim, I now have the stack working fine using this SNAPSHOT.
Could this version be released and pushed to clojars.

Many thanks, its really appreciated.

@henryw374
Copy link

Hi - I am also using this snapshot version to solve the same issue.

cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jcrossley3 @alexdforeman @henryw374