Closed jmarshall closed 5 years ago
Travis' happy, ready to go in.
I'm going for a new release next week.
Yay for a new release. BTW the Build.PL version check on Bio::SeqFeature::Lite isn't working for me (that module doesn't have a $VERSION?!) — is it working for you?
The new release should also take this edge case into account, it's on my agenda. The mess depends on the recent release of BioPerl. Starting from 1.7.3, they've switched to the customary way of specifying module versions (one global variable per module) while at the same time they've removed completely Bio::Root::Version. Given this, I'll make Bio::SeqFeature::Lite an explicit requirement in the Build script but with most up-to-date version of BioPerl. This is unfortunately forces whoever has already installed BioPerl <= 1.7.2 to install the most up-to-date version, as the focus here is on allowing automated installation mechanisms like cpan/cpanm to work. They will install the latest BioPerl version and won't complain they cannot detect a version. I couldn't see any alternative workaround.
This was failing when running perl Build.PL
by hand with bioperl-live HEAD (BioPerl-v1.7.5-3-g7cc47700c) in $PERL5LIB. Hmmm…
Have you maybe tried requires => { …, 'Bio::SeqFeature::Lite' => 0 }
which the documentation suggests checks for the module's presence but is okay even if it doesn't have a version number?
bioperl is really giving me nightmares, and not only me. All ensembl has to stick to one very specific version (1-6-924).
Ok, let's go for the module presence option. Thanks again.
It's in.
Hi Alessandro,
This fixes #82 et al. Fortunately the problem was with the use of HTSlib's
bcf_get_format_foo()
API functions and not some XS-related mystery!