Support tracking dependencies by branch #16
Conversation
Lets make running tests easier by adding a Make command for it
In addition to `version` and all the features around that, we can also explicitly track a remote `branch` that will be fetched/updated when `modulo update` is run.
Make for the `--unmanaged` flag on `add` to have an optional argument of a commit or a branch. However this lead to complications around other flags being passed such as `add blah --unmanaged -u -v`. To resolve that issue, the properties on `Option` were move to `public` so the add command could try its best to still apply arguments when they were inadvertantly swallowed by the now `--unmanaged` optional value. Also the `unmanagedValue` is tracked in the `.modulo` file like `branch` was but is more generic supporting an entire commit hash or a branch name
|
Expanding on the message in The main weirdness is that it doesn't look like ELCLI supports an optional value. Which makes sense, that's a unique use case. It could be extended to support just that but for now, the fastest change I could do was to make the properties on |
Rather than have the add command hack in support for optional values to flags make it a core feature of `ELCLI`. That seems like the proper place to handle this situation and also doesn't break existing functionality/assumptions in all the other uses/tests.
dmiedema
force-pushed
the
TrackBranch
branch
from
1d4b125 to
1a3a5dc
Compare
|
I had an understanding of what this was going to be more akin to what @bsneed had. The I also think the interface should be normalized. The So: $ modulo add --version <version|hash|branch>
$ modulo add --unmanaged <version|hash|branch|nothing>Maybe |
| @@ -17,6 +17,9 @@ public struct DependencySpec { | |||
| var repositoryURL: String | |||
| // version or version range | |||
| var version: SemverRange? | |||
| /// Optional unmanaged property to track | |||
| /// such as a branch name, commit hash, or nothing | |||
| var unmanagedValue: String? | |||
There was a problem hiding this comment.
Is unmanagedValue the right name for this? Maybe we could use unmanagedBranchOrHash, unmanagedCheckout. Honestly I'm not so sure I agree with the --unmanaged name option. It isn't unmanaging anything, it's more not using a version. unversioned?
|
Yeah, Maybe Maybe something like That might be more explicit and easier to understand also. It would render the changes in ECLI unnecessary (although they may be useful on their own? I'm not sure of all of its use cases) as well. |
|
Nah, these comments are getting away from the point. Unmanaged = You manage it yourself. Checkout whatever branch/hash/tag you desire. Optionally, it will do the initial checkout for you, nothing more. You want it managed, you use a version. The end. No branches/hashes/non-semver tags, etc. @dmiedema hit me up on slack if this doesn't clear it up. |
In addition to
versionand all the features around that, we can alsoexplicitly track a remote
branchthat will be fetched/updated whenmodulo updateis run.Add
make testcommandLets make running tests easier by adding a Make command for it