slendr 1.0.0

The above is implemented in PR #157.

slendr 0.9.1

slendr 0.9.0

slendr 0.8.1


WARNING: SLiM 4.1 which has just been released includes a couple of backwards incompatible changes related to the implementation of spatial maps which prevent the current version of slendr’s slim() function from working correctly. If you rely on the functionality provided by the slim() function, you will have to use SLiM 4.0. (Note that if you want to have multiple versions of SLiM on your system, you can either use the slim_path = argument of slim() or specify the $PATH to the required version of SLiM in your ~/.Renviron file just like you do under normal circumstances). Porting slendr for SLiM 4.1 is being worked on.

slendr 0.8.0

slendr 0.7.2

slendr 0.7.1

If spatial dependencies are not present but a spatial slendr function is called regardless (such as world(), move(), etc.), an error message is printed with an information on how to install spatial dependencies via install.packages() as above.

Why? It’s true that the main reason for slendr’s existence is its ability to simulate spatio-temporal data on realistic landscapes via SLiM. However, in practice, most of the “average” uses of slendr in the wild (and in classrooms!) rely on its traditional, non-spatial interface, with its spatial features being used comparatively rarely at the moment (except for some cutting-edge exploratory research). Given that setting up all of the spatial dependencies can be a bit of a hurdle, we have decided to make these dependencies optional, rather than force every user to go through the process of their installation whether they need the spatial features or not.

slendr 0.7.0

This is an emergency upgrade to match the latest pyslim 1.0.3 due to a serious bug in recapitation. See here and here for an extensive discussion during the process of identification of the bug and its eventual fix. For a brief summary of the practical consequences of this bug, see this thread by pyslim’s developer and its formal announcement here.

Note: Loading library(slendr) will prompt a message “The legacy packages maptools, rgdal, and rgeos, underpinning the sp package, which was just loaded, will retire in October 2023. […].” This is an internal business of packages used by slendr which unfortunately cannot be silenced from slendr’s side. There’s no reason to panic, you can safely ignore them. Apologies for the unnecessary noise.

slendr 0.6.0

This is a relatively large update, which unfortunately had to be released in haste due to the retirement of the rgdal package – a significant dependency of the entire spatial R ecosystem which is being phased out in the effort to move towards modern low-level geospatial architecture. Although slendr itself does not depend on rgdal, many of its dependencies used to (but won’t in the short term, hence the push to remove the rgdal dependency). The most significant update has been the addition of IBD functionality of tskit, as described below. However, large part of this functionality has not been extensively tested and should be considered extremely experimental at this stage. If you would like to use it, it might be safer to either wait for a later release in which the IBD functionality will be more stable, or use the underlying, battle-tested Python implementation in tskit.

    NOTE: Due to Python setup issues on some systems which have been
    causing trouble particularly for novice users, calling library(slendr)
    no longer activates slendr's Python environment automatically.
    In order to use slendr's msprime back end or its tree-sequence
    functionality, users must now activate slendr's Python environment
    manually by executing init_env() after calling library(slendr).
    (This note will be removed in the next major version of slendr.)

Users have to call init_env() to manually activate the Python environment of slendr (see note under version 0.5.0 below for an extended explanation).

slendr 0.5.1

slendr 0.5.0

Motivation for the change: A small proportion of users have been experiencing issues with broken conda environments and various other issues with Python virtual environments in general. It’s hard to guess how frequent this has been, but experience from workshops and courses suggests perhaps 1 in 20 of users experiencing Python issues which hindered their ability to use slendr .(Fun fact: the first user-submitted GitHub issue upon releasing the first version of the slendr R package was… a Python virtual environment issue).

Explanation: Activating Python environments automatically upon calling library(slendr) has been a popular feature because it hid away most of the complexities of the R-Python interface that powers slendr’s tree-sequence functionality. This was particularly convenient for many slendr users, particularly those who have no experience with Python at all.

Unfortunately, in cases where a Python virtual environments with tskit/msprime/pyslim on a user’s system ended up corrupted (or if anything else at the Python level got broken), the automatic Python environment activation performed by the library(slendr) call failed and slendr was not even loaded. Sadly, this completely pulled the rug from under slendr and there was nothing that could be done about it from its perspective (the issue happened at a low-level layer of embedded-Python before slendr could’ve been loaded into R). Solving these issues was not difficult for experienced users, but many slendr users have no experience with Python at all, they have never used conda, they don’t understand the concept of “Python virtual environments” or how the R-Python interface works. And nor should they! After all, slendr is an R package.

Splitting the Python virtual environment activation step into its own init_env() function means that library(slendr) now always succeeds (regardless of potential underlying Python issues on a user’s sytem), making it much easier to diagnose and fix Python problems from R once the package is loaded.

So, to recap: library(slendr) no longer activates slendr’s isolated Python virtual environment. In order to simulate tree sequences and analyse them using its interface to tskit, it is necessary to call init_env(). This function performs the same Python-activation steps that library(slendr) used to call automagically in earlier slendr versions. No other change to your scripts is necessary.

> ts_f3(ts, A = c("p1_1", "p1_2", "p1_3", "p1_4", "p1_5"),
            B = c("p2_1", "p2_2", "p2_3"),
            C = c("p3_1", "p3_2", "p3_3", "p3_4"))

# A tibble: 1 × 4
  A                        B              C                         f3
  <chr>                    <chr>          <chr>                  <dbl>
1 p1_1+p1_2+p1_3+p1_4+p1_5 p2_1+p2_2+p2_3 p3_1+p3_2+p3_3+p3_4 0.000130

This gets unwieldy rather quickly, especially when dozens or hundreds of samples are grouped together as populations. The new syntax allows the following shortcut via customised group names leveraging the standard named list functionality in R:

> ts_f3(ts, A = list(group_one = c("p1_1", "p1_2", "p1_3", "p1_4", "p1_5")),
            B = list(group_two = c("p2_1", "p2_2", "p2_3")),
            C = list(group_three = c("p3_1", "p3_2", "p3_3", "p3_4")))
# A tibble: 1 × 4
  A         B         C                 f3
  <chr>     <chr>     <chr>          <dbl>
1 group_one group_two group_three 0.000130

This is more readable and in line with some other tskit-interface functions of slendr which used this functionality via their sample_sets = argument (ts_divergence(), ts_diversity(), etc.). (#ac5e484)

slendr 0.4.0

slendr 0.3.0

slendr 0.2.0

slendr 0.1.0