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

better versioning of parent modules #321

Closed
achubaty opened this Issue Nov 8, 2016 · 4 comments

Comments

Projects
None yet
1 participant
@achubaty
Copy link
Contributor

achubaty commented Nov 8, 2016

I ran into this issue while dealing with #319.

For non-parent modules (i.e., child modules), it is straightforward to download a particular version of a module, which is essential for reproducibility.

downloadModule("fireSpeadLcc", version = "1.1.0") ## always get v1.1.0
downloadModule("fireSpeadLcc", version = "1.1.1") ## always get v1.1.1

But the version for a parent module doesn't quite work the same way, because we are not tracking the versions of the children!

downloadModule("LCC2005", version = "1.1.1") ## always get v1.1.1 of parent
                                             ## but unknown versions of children!

While this does retrieve v1.1.1 of the parent module, depending on when it's run you will get different child module versions (because parent modules always download the most recent version of their children). This morning you would get fireSpreadLcc v1.1.0 but this afternoon that child module was bumped to v1.1.1.

This means that using parent modules is currently irreproducible out-of-the-box!

@eliotmcintire we need to record the version of the children in the parent module's metadata, which will require several tweaks:

  1. using the existing version slot, allow a named list/vector of numeric_versions to be stored
  2. ensure that downloadModule properly matches child version to that read from the parent's metadata
@achubaty

This comment has been minimized.

Copy link
Contributor Author

achubaty commented Dec 8, 2016

using a named list for versions also allows us to include the SpaDES version:

version = list(SpaDES = '1.3.1.9017', child1 = '0.1.0', child2 = '0.2.1', ...)

since we currently aren't enforcing the SpaDES version , this provides a better mechanism to do so.

achubaty added a commit that referenced this issue Feb 22, 2017

improve module versioning (#321); bump version to 9044
* use named list instead of `numeric_version` in module metadata
* remove unused function `versionWarning()`
* add new function `moduleVersion()`
* update sample modules
* update test module in module repo
* update tests
@achubaty

This comment has been minimized.

Copy link
Contributor Author

achubaty commented Feb 22, 2017

@eliotmcintire Implemented in SpaDES but not yet implemented for the modules in the SpaDES-modules repo (it is backwards compatible, but we shouldn't update the modules until the CRAN version of the package is updated).

@achubaty

This comment has been minimized.

Copy link
Contributor Author

achubaty commented Feb 23, 2017

Also TO DO: implement a nice way to use the version info from the module metadata and implement strict checking of parent/child versions. Currently, it's possible to download the correct module versions but then if the user or another module updates one of the child modules, running the parent won't catch the change.

@achubaty achubaty self-assigned this Feb 23, 2017

@achubaty achubaty added this to the v1.4.0 milestone Apr 4, 2017

@achubaty

This comment has been minimized.

Copy link
Contributor Author

achubaty commented Jan 25, 2018

This issue was moved to PredictiveEcology/SpaDES.core#31

@achubaty achubaty closed this Jan 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.