-
Notifications
You must be signed in to change notification settings - Fork 1
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 submodule updates to the release script. #75
Conversation
|
||
cd $ROSETTA | ||
find . -name '.git' -type d -prune -exec rm -rf '{}' '+' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clever
Rocco a few thoughts: Re converting to release: for current approach to work we will need to make sure that release script init submodules after initial cloning (somewhere around ~here https://github.com/RosettaCommons/main/blob/master/tests/benchmark/tests/release.py#L151 ). This is because right now we explicitly checking out any released submodules here: https://github.com/RosettaCommons/main/blob/master/tests/benchmark/tests/release.py#L108 Re 'Definitely want to release' list: are you sure about |
Re 'Do we need to include these with the standard (non-PyRosetta) release (@lyskov) - we can trim these out specifically.': - i think if we already including them with source release (at least i though so) which i think is good so our users could compile PyRosetta without extra downloads. |
This PR adds the submodule init to the I was unaware of the specific cloning of binder and pybind11 in the release scripts. We can keep the submodules in the release, although there is now a redundancy in the update, with a difference in behavior. The version in the existing python script will checkout the repos' current version of master, rather than whatever submodule version was pinned for the version of Rosetta being released. I'd vote for matching the pinned version, myself. -- (Note that my initial thoughts were that (theoretically speaking) people are supposed to be licensing PyRosetta separately, and compiling from the standard Rosetta source distribution would allow them to bypass that. But apparently we're not concerned about that, which is fine too.) Regarding But I would strongly argue that we should be releasing such scripts, and release should effectively be an opt-out process, rather than an opt-in process. If there's some other mechanism for labelling not-to-be-released files in the (That said, I can see the argument that the pyrosetta_scripts directory is probably less useful for the command line release of Rosetta, so it might make sense to only release the directory for the PyRosetta distributions, rather than the source/command-line distributions.) |
@roccomoretti re scripts marked for public: i just looked this up and think i confuse this with rosetta-scripts-scripts repository (more on that below). I do agree with you that having ppl to opt-out from release is better strategy for us so lets assume that everything in pyrosetta-scripts repository is 'releasable' for now. And this bring us to issue of what is releasable in rosetta-scripts-scripts repository. I see this directory (which i though i saw in PyRosetta scripts earlier) https://github.com/RosettaCommons/rosetta_scripts_scripts/tree/master/scripts and in it we see both
I agree that using 'pinned-version' is a better approach, so i guess lets comment lines 121 and 122 from here https://github.com/RosettaCommons/main/blob/master/tests/benchmark/tests/release.py#L121 for now? re should we bind Binder and Pybind11 with Rosetta source release: - i think having just one package will be easier for us and for our academic users. Non academic users need to get separate licenses anyway and i doubt if splitting into multiple packages will stop rogue-non-academic-user from compiling PyRosetta. So my vote will be to keep number of packages at minimum and have only one Rosetta-source release package that contain all public data. |
Addresses RosettaCommons/main#3138 |
…ease Add submodule updates to the release script. This PR makes it such that the release process will release submodule contents in the standard release. The standard trimming approach is used, so any directory named 'pilot' under main/ will be removed (including those in submodules). We can add other trimming rules, if needed.
Now that we're using submodules more heavily, we really need to be releasing their contents.
This PR makes it such that the release process will release submodule contents in the standard release. The standard trimming approach is used, so any directory named 'pilot' under main/ will be removed (including those in submodules). We can add other trimming rules, if needed.
Current submodules which will be added to the public Rosetta release:
Definitely want to release:
Probably good to release:
Do we need to include these with the standard (non-PyRosetta) release (@lyskov) - we can trim these out specifically.