zcaudate-me / lein-repack

moved -> 'lucid.distribute'
65 stars 5 forks source link

Include SCM info in generated subprojects #7

Closed RyanMcG closed 9 years ago

RyanMcG commented 9 years ago

Leiningen attempts to automatically determine SCM info if not present in the project.clj. Even when this is possible, repack does not include the scm info in generated projects. I think it should.

zcaudate commented 9 years ago

that's not a problem =) are there any other keys that should be included as well?

RyanMcG commented 9 years ago

@zcaudate I'm not sure about other keys. I haven't considered it much.

It seems to me that passing scm information through is not as easy as it sounds. Lower-level leiningen functions related to the scm tag are private and they are used when the pom file is written. It uses the :root in the project map and looks for scm artifacts from there (e.g. a .git directory`).

If you think of a solution I'd be happy to here it. It seems to me, that in an ideal world at least one of the following would be helpful:

  1. lein-repack does not use interim project.cljs and just manipulates :source-paths in project maps to create the necessary artifacts. This way :root would be consistent.
  2. Leiningen would provide, and use in core, a fill-in-project-scm function which takes and returns a project map, filling in an scm key if none exists using the same semantics leiningen currently has for determining scm info.
zcaudate commented 9 years ago

@RyanMcG: Both options are nice... a third option can be done using #'leiningen.pom/private-function to call the necessary functions or just copy it outright.

Just wanted to know your thoughts on the merits of each..

RyanMcG commented 9 years ago

@zcaudate I did not know about #'leiningen.pom/private-function... I'm not sure it exists in 2.5.0. http://crossclj.info/ns/leiningen/2.5.0/leiningen.pom.html.

Either way, invoking private vars in leiningen seems less than ideal. SCM info is only generated when pom file is being written. Since lein-repack works by creating interim projects this is a too late. If we did not create interim projects this would be easier. I'm going to do a bit more digging on option 1 since option 2 requires modifying a dependency.

It seems to me that transforming the original project.clj to a project map to more project.cljs just so they can be turned into a project map and pom again results in a loss of control. I suspect option 1 may result in a library that is also easier to test and simpler (if it is possible). Again, I have more digging to do.

zcaudate commented 9 years ago

This has been added in the newest master