new package Rscape-2.0.0-k #5344
Conversation
R/Rscape/build_tarballs.jl
Outdated
| version = v"2.0.0-k" | ||
|
|
||
| file_version_str = if isempty(version.prerelease) | ||
| "$version" | ||
| else | ||
| "$(version.major).$(version.minor).$(version.patch).$(first(version.prerelease))" | ||
| end |
There was a problem hiding this comment.
We can't really use prerelease tags in version numbers of packages, maybe one day we'll explicitly prohibit it. I usually do the other way around: write down the version string used by upstream, and build up the version we want to use out of it, maybe something like
VersionNumber(replace(file_version_str, r"([0-9]+\.[0-9]+\.[0-9]+).*" => s"\1"))?
There was a problem hiding this comment.
Thanks for the review!
I made the change, though i have to admit i think it would be nice to use the correct version numbers for binary packages. Not sure if that would be have to be done at the Pkg or the BinaryBuilder level. Or maybe there is something i am missing :)
There was a problem hiding this comment.
It's a limitation of Pkg, it doesn't really like anything outside of X.Y.Z versioning scheme, with JLL packages we're already outside of it with the use of the build number, which causes some issues. Also, lots of projects have very wild versioning schemes, completely outside of the X.Y.Z-prerelease+build scheme, we can't possibly cater for all of them so we have to do some normalisation anyway.
R/Rscape/build_tarballs.jl
Outdated
| ExecutableProduct("MetamakeDemos.pl", :MetamakeDemos_pl), | ||
| ExecutableProduct("pdb_parse.pl", :pdb_parse_pl), | ||
| ExecutableProduct("r2r_msa_comply.pl", :r2r_msa_comply_pl), | ||
| ExecutableProduct("SelectSubFamilyFromStockholm.pl", :SelectSubFamilyFromStockholm_pl), |
There was a problem hiding this comment.
Note that usually we use ExecutableProduct for binary executables (ELF/COFF/MachO files), not interpreted scripts, because they aren't standalone (modulo required libraries) and need an interpreter to actually run. FileProduct should be used instead.
There was a problem hiding this comment.
I made the change, and also removed the MetamakeDemos.pl script as it needed the source tarball directory to work.
I guess there could be some difficulty in using the FileProduct scripts in the case that they in turn call ExecutableProducts, as one would have to manually set up the environment (setenv) like it is done for an ExecutableProduct. I eyeballed that this is not the case here.
Just for future reference, if that were to be the case (script calling executable installed by _jll), would one then use ExecutableProduct or still choose FileProduct?
There was a problem hiding this comment.
Just for future reference, if that were to be the case (script calling executable installed by _jll), would one then use ExecutableProduct or still choose FileProduct?
Eh, good question. Maybe we could do an exception for those cases, but it remains the problem that you may not be able to run the script if you're missing the interpreter at the expected path (Windows being the usual suspect)
Co-authored-by: Mosè Giordano <[email protected]>
- perl scripts now use FileProduct instead of ExecutableProduct - remove MetamakeDemos.pl from products, it needs the source directory Co-authored-by: Mosè Giordano <[email protected]>
R-scape is a package for predicting RNA secondary structure using evolutionary covariation observed from multiple sequence alignments.
http://rivaslab.org/
http://eddylab.org/R-scape/