-
Notifications
You must be signed in to change notification settings - Fork 5
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
Changing the way tree-sequence outputs are handled by default #100
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For whatever reason msprime occassionally gives this error: Traceback (most recent call last): File "/var/folders/d_/hblb15pd3b94rg0v35920wd80000gn/T//RtmpjyLc4w/filee337593377b2/script.py", line 198, in <module> ts = msprime.sim_ancestry( File "/Users/mp/Library/r-miniconda-arm64/envs/msprime-1.1.1_tskit-0.4.1_pyslim-0.700/lib/python3.8/site-packages/msprime/ancestry.py", line 1207, in sim_ancestry sim = _parse_sim_ancestry( File "/Users/mp/Library/r-miniconda-arm64/envs/msprime-1.1.1_tskit-0.4.1_pyslim-0.700/lib/python3.8/site-packages/msprime/ancestry.py", line 1008, in _parse_sim_ancestry random_generator = _msprime.RandomGenerator(random_seed) ValueError: seeds must be greater than 0 and less than 2^32
Just for completeness - this is purely an UI change, nothing has changed in terms of simulation itself. In terms of reproducibility, the same random seed will result in the same tree sequence output even in the latest version. |
This makes sense, and looks like you have a good solutoin. |
Checks passed. Merging the PR now and resubmitting to CRAN. 🤞 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The CRAN submission process has progressed smoothly so far. slendr got lots of great feedback, especially with regards to documentation which is now much nicer and more robust than before.
So far so good.
Unfortunately, CRAN folks pointed out that the current way handling of tree-sequence output files in slendr is incompatible with CRAN policies. In fact, the way the outputs have been handled is explicitly illegal as far as CRAN is concerned.
The problem is with how storing tree sequence outputs has been automatically handled so far. Briefly, for convenience reasons, unless a full path to a tree-sequence output was provided to
slim()
ormsprime()
interface functions, outputs were by default saved to a user-defined model directory together with other slendr files.Example:
This is all beautiful, except the fact that CRAN considers it illegal to write anything anywhere unless it is into
/tmp/
(or equivalent on different OS). And no, it does not matter that the model directory is often in a/tmp/
itself, or that the interface has been designed with themodel
object and its associated directory being the central component of the simulation, where tree sequences are put by default. Upon reflection, although this seems to be too strict at first (plenty of Google issues related to this), it is entirely reasonable position to take from the perspective of CRAN.This has forced me to change the way tree sequence outputs are handled. Not in a dramatic way, but still in a way that’s backwards incompatible with the way I’ve been doing things since the very beginning. I’m glad I discovered this before submitting the paper, doing this during the revisions would be a huge annoyance for… basically everybody.
Here's the new behavior that hopefully adheres to CRAN's super strict -- and, in hindsight, extremely reasonable -- policies:
Alternatively, one can also do:
Or even this (which is closest to the way things have been done in the past):
Pinging people who have been involved in slendr development or have been using slendr for their work: @bhaller, @petrelharp, @mkiravn, @FerRacimo, @MoiColl, @dangliu, @awohns, @jaurbanChicago, @archgen, @emmaprantoni. Once the new version is merged to the main, your code might need some changes in case you update at some point.
Once the automated GitHub Actions tests pass, I will merge the PR and resubmit slendr to CRAN. I will ping you here, then you'll be able to get the latest version of slendr with
devtools::install_github("bodkan/slendr")
.