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

Add version-listing tool #1

Merged
merged 4 commits into from Apr 20, 2017
Merged

Conversation

jrising
Copy link
Member

@jrising jrising commented Apr 5, 2017

Finds the installed module versions and git repository hashes of a set of modules, to be included in output file dependencies.

@jgerardsimcock
Copy link
Contributor

I agree keeping track of dependencies is useful. And is it possible to specify this ahead of time with a requirements.txt?

@jrising
Copy link
Member Author

jrising commented Apr 19, 2017

I think there are a few problems with this idea:

  • The requirements.txt will not specify the most important dependency for any file, which is the hash for the repo that generated it (that is, the one that contains both the script that generated the file and the requirements.txt file).
  • Generally, a repository will generate multiple files (e.g., like socioeconomics does), and while the requirements.txt file needs to specify the libraries needed for all of these, each file should only record the libraries that are actually necessary for it.
  • Even if we version all of our repos so that they could be in a requirements.txt file, there are plenty of reasonable cases where the version we want to use will just be the master development branch.

@delgadom
Copy link
Member

What about tagging the commit that produced major outputs and then sticking the repo and tag ID in the metadata? That seems like the "industry standard" way to do this for non-released packages, right?

Then you have the package dependencies in the repo, and then include in the output file's metadata the repo url, the tag ID, and the data dependencies. That provides exactly how much information you need to reproduce the results, right?

@jrising
Copy link
Member Author

jrising commented Apr 20, 2017

The goal of this was to make the process of recording accurate dependencies easier. Unless I misunderstand it, your proposal seems strictly less easy than filling it out by hand and equally error-prone.

@coveralls
Copy link

coveralls commented Apr 20, 2017

Coverage Status

Coverage decreased (-9.9%) to 55.435% when pulling c3630ed on jrising:versioncheck into 1459b50 on ClimateImpactLab:master.

@coveralls
Copy link

coveralls commented Apr 20, 2017

Coverage Status

Coverage decreased (-9.9%) to 55.435% when pulling 52a1086 on jrising:versioncheck into 1459b50 on ClimateImpactLab:master.

@coveralls
Copy link

coveralls commented Apr 20, 2017

Coverage Status

Coverage decreased (-9.9%) to 55.435% when pulling e2cf6da on jrising:versioncheck into 1459b50 on ClimateImpactLab:master.

@delgadom delgadom merged commit 3780011 into ClimateImpactLab:master Apr 20, 2017
@jrising
Copy link
Member Author

jrising commented Apr 21, 2017

Thanks! I shared the changes you made with Jong-kai.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants