Make sure slendr's SLiM back end can run both under SLiM 3 and SLiM 4
bodkan opened this issue · 3 comments
Moving a discussion with @bhaller over from this PR.
One question: is slendr now SLiM 4 compatible? I hope so. The changes needed ought to be fairly minimal, and with a little elbow grease it should be possible to have your scripts run on both 3.7 and 4.0 (let me know if you need any advice on that). It would be great if the SLiM 4 release, which I plan to do in early to mid August, did not break slendr and create a crisis. :->
I had absolutely no time to test things with SLiM 4 just yet :( But it is important thing to check, so I opened an issue (#98) and will make sure to test this soon. Would you say that running the current slendr unit tests against the SLiM 4 binary be a good start? I.e. that only a few syntactic/semantic would be needed that I could fix a few errors that might arise? In any case, I will post potential issues there and ping you when necessary. Thanks for bringing this up.
I expect it to only be syntactic tweaks, yes. By and large, SLiMgui will offer to "autofix" the issues for you if you open a generated slendr script in SLiMgui and run it; each error encountered should produce a new "autofix" suggestion. Accepting those fixes will get you a working SLiM 4 script (although there might be a case or two where autofix is not sufficient). The SLiM 4 beta has links to more information about exactly what changed. The thing that might bite you the most is that sim.generation no longer exists; it is now community.tick or sim.cycle, to get the same sort of information (see the docs regarding what the difference between those two things is). If you use it a lot, you might find it simpler to just make a user-defined function named
time()that checks the version number and returns the correct property, or something. Sorry about that; I had my reasons, but the changeover has created a lot fo work for me, too. :->
This is all really valuable info, thank you.
Your timeline for releasing SLiM 4 is pretty much aligned with my optimistic timeline for getting the slendr paper out (end of summer, assuming I can submit the package to CRAN and submit the paper itself in the next 2-3 weeks). Although a paper has practically only minor impact on the lifetime of a software, I wanted to use it as an opportunity to mark slendr with a semantically important tag, let's say 1.0 (I've been tracking versions in the 0.x series so far).
Would you say -- given this timeline and the fact that so far nobody is using slendr for long-term work so far and that this will hopefully start happening only after the paper is out -- that it would make sense to lock slendr to a SLiM 4 release? I.e. make SLiM 4 a requirement? Again, because all the slendr work out there is still experimental, there doesn't seem any harm in this.
This could help me with slendr maintenance moving forward, rather than having to maintain two back-end SLiM scripts potentially for a very long time? I feel like I'm easily in the phase where this would not give anyone headaches so the long-term benefit is very appealing from my perspective.
[I know the slendr back-end script is purely an internal business for 95% of users and they might not notice any differences between the SLiM 3 and 4 back ends, but still.]
Locking to SLiM 4 seems fine to me, if you don't have any users who will be overly annoyed by that choice. :-> I don't think you would need separate SLiM 3/4 back-end scripts; the differences are not that major. But it would nevertheless be annoying to have to maintain compatibility with both, so sure, ditch SLiM 3. :->
Closing this issue in favor of this pull request.
I don't think porting the SLiM back end to SLiM4 will be too difficult (the changes so far seem mostly cosmetic) but I did just now notice that the Python dependencies required for processing tree sequences changed as well and that will require a bit more work (and reading).