[Bioperl-l] Build.PL? Can't I just use bioperl-live from github? (rosalind.info looks cool)

[Fields, Christopher J]

On Jun 26, 2014, at 8:46 AM, Jay Hannah <jay at jays.net> wrote:

> On Jun 26, 2014, at 12:04 AM, Fields, Christopher J <cjfields at illinois.edu> wrote:
>> Other module sets we have moved out are into separate distributions are Bio::Assembly, Bio::EUtiities, Bio::FeatureIO, but they’re not as break-y as a missing Bio::Root :)  You could simply grab the latest github repo and add it to your PERL5LIB.  At the moment I don’t think it has a pass-through Build.PL/Makefile.PL (we’re using Dist::Zilla).
> 
> Ah, there we go, thanks. I'm back in business.   :)
> 
> $ export PERL5LIB=~/src/bio/bioperl-live/:~/src/bio/bio-root/lib
> $ perl dna.pl
> AGCTTTTCATTCTGACTGCAACGGGCAATATGTCTCTGTGTGGATTAAAAAAAGAGTGTCTGATAGCAGC
> GCTGCTATCAGACACTCTTTTTTTAATCCACACAGAGACATATTGCCCGTTGCAGTCAGAATGAAAAGCT
> 
> Yay! I had forgotten that bit, if I had known it at some point.
> 
> ---
> 
> I know little about Dist::Zilla, but I've been poking around in 
> 
> https://github.com/bioperl/dist-zilla-pluginbundle-bioperl
> 
> Shouldn't Build.PL be gone from bioperl-live, and a dist.ini added?

At some point yes; if you want to take this on you are more than welcome.  We’ve basically focused on doing this with the split-out code for the time being but haven’t worked on the same for bioperl-live…

Well, namely b/c of one complicating factor: there are a lot of configuration details in the current Build.PL which a dist.ini would have to deal with (DB test setup, network-based tests, etc).  Something to keep in mind.

> On Jun 26, 2014, at 7:33 AM, Chris Maloney <voldrani at gmail.com> wrote:
>> Could you switch master into a feature branch, and put master back to some last-known-good commit?
> 
> I agree master should be usable via Build.PL or dist.ini. Currently it's halfway transitioned between the two (broken)?

tl;dr - We should forego any further 1.6 releases and release Bio::Root and a new 1.7 release off ‘master' to CPAN.  dist.ini integration could happen along the way.

Okay, the long bit...

Chris, I’m a bit confused.  Maybe clarify: what is a ‘last-known-good commit’?  One including Bio::Root?  By this definition the true ‘stable’ branch at this point is still v1.6.x, where we have been pulling over code changes from master on a regular basis.  The key problem is a missing Bio::Root::Root v1.7 on CPAN.  Once Bio::Root is on CPAN it can be installed completely separately and would be pulled in as a dependency.  If you really need to use ‘master’ now, have Bio-Root in your PERL5LIB for now if you want the latest developer code.  

We’ve repeatedly stressed over the years, 'master' is currently a development branch and should not be expected to be stable at all times (the same has been said of SVN trunk in those days).  However, maybe the best long term solution would be some middle ground, maybe if we frame the question a little differently.  What is the most common use-case for a full git checkout by a typical user?

If it is users getting the latest stable core code or bug fixes, we can rethink things a bit.  The current state of things (expecting ‘master’ to be stable) incurs significant pressure on us to keep the ‘master’ branch in tune, which is really a problem.  We simply can’t make big changes to code easily.  It’s a real pain in the ass, b/c we have a lot of people who would like to make said changes but work in fear of breaking things.  Forward movement stagnates.  Things that need to be fixed (and possibly horribly broken in the meantime) can’t be.  Things that need to be brought in (like Greg Jordan’s Tree work or Yun Jin’s GSoC work on alignments) can’t easily be merged.

So, if users are checking out code expecting it to be stable, then the default *checkout* branch should be that one  It should NOT be development-based and not be version-bound, e.g. not the v1.6.x branch.  This branch would work  —>as long as the required dependencies are installed from CPAN <— (emphasis on that last bit).  

That would be easy enough to do.  But, any way we go about it, I can’t see this being possible until Bio::Root is on CPAN, and putting Bio::Root on CPAN on it’s own will effectively kill any future 1.6.x releases.  Not to mention, anyone keeping Bio::Root::Root as the base requirement to pull in all of BioPerl will probably get a nasty surprise (which in reality is due to listing the wrong dependency on their part, but it’s an issue that will come up).

So I think we should just work towards a 1.7 release, with a Bio::Root release just prior, and forego any future 1.6 releases.  Sound good?

> Should I try to hack out a dist.ini for bioperl-live? Should that be master? Or is there a known historical point which should be master for now?

As a separate stable/development branch doesn’t exist yet my suggestion is to work off a branch of ‘master' for now for any dist.ini stuff.  Sound good?  Should be possible to merge it in 

> Thanks again for your time,   :)
> 
> j
> 

No problem, hack away (and keep us posted here!)

-c