[Bioperl-l] Splits again
cjfields at uiuc.edu
Thu Jun 28 09:07:24 EDT 2007
On Jun 28, 2007, at 5:31 AM, Hilmar Lapp wrote:
> On Jun 28, 2007, at 12:51 AM, Jason Stajich wrote:
>> seems like we really need to do this first so that we have a stable
>> release that can be followed by CVS -> SVN migration, then consider
>> major changes to the repository structure and release packaging, and
>> potential deprecation and incorporation of other modules.
> I agree we need to discuss a path towards 1.6, but I think that
> should be kept separate from the cvs->svn migration. Otherwise one
> stalls the other (by stopping people who seem to have the energy and
> motivation right now to do one but not the other) for no really good
It's good to discuss it as long as it doesn't take time and energy
away from other priorities.
>> I assume there is no chance that we'd have a 1.6 candidate by BOSC
>> next month?
> I'm not sure that's feasible to be happening but if someone steps up
> it maybe it is.
Maybe a 1.5.3 and (if we work hard on it) a 1.6 soon after. Then
maybe work on partitioning if everyone's up for it and a scheme is
>> Will it be productive to schedule a fair amount of time at BOSC
>> discussing how to partition out the packages into separate sub-
>> packages after we've done a successful release rather than trying to
>> change things right now?
> I agree. I also don't think that people are partitioning right now
> (other than the existing partitioning), though maybe I'm mistaken.
The original proposal was based on Steve's idea of splitting up
core. I don't think a partition is feasible at this point, at least
until we put more thought into it (our energy should be focused
elsewhere), but it's well worth discussing as a future path.
At this time there are two proposals:
1) Steve's and my 'split into discrete sections' proposal, where we
split core into self-sustaining sections with a common core listed as
a dependency, tying installation of all together with a Bundle or
2) Sendu's 'break everything up' approach where all modules are
submitted independently to CPAN, with their own tests, dependencies,
There are advantages and disadvantages to both approaches. Not sure
if CPAN would go for the latter (it's pretty drastic), but I don't
know for sure. If you want in on that discussion (in this thread)
feel free to join in! The more the merrier!
>> It would probably mean moving Bio::Graphics, Bio::DB::GFF and
>> Bio::DB::SeqFeature and gff tools for Gbrowse into separate packages
>> so they could be released more regularly on par with Gbrowse
> Possibly. I'm not fully sure why those modules couldn't also be
> released more often out of the "main trunk" of modules. In Java/ant,
> it'd be relatively easy to write build script filters that select the
> appropriate modules and package them on the fly. I'm not sure whether
> the build tools for Perl can do that too, though.
Both approaches above would probably use Module::Build to install
other bioperl dependencies, each of which could have it's own
dependency set, possibly using a Bundle to tie everything together.
>> Also I think someone needs to figure out Bio::Tools::GFF
>> vs Bio::FeatureIO -- what do we want to do?
> I believe FeatureIO has the ontology download tied into it?
From recent posts here and on the gbrowse mail list by Scott and
Lincoln, it seemed like they were moving away from using Bio::DB::GFF
and were trying to get users to switch to Bio::DB::SeqFeature. Maybe
should get a more direct response?
More information about the Bioperl-l