[Bioperl-l] Splits again
jason at bioperl.org
Wed Jun 27 23:51:32 EDT 2007
Hey guys - I'm wading in a bit late as I haven't had time to keep up
with whole discussion.
So you are suggesting 800+ individual CPAN modules? I don't think
that is a good idea. Why would you split up Bio::Seq::RichSeq and
Bio::Seq into two separate packages for example? I think if you
really want to move away from the monolithic install it has to be
more logical by function - but I am not that optimistic that this is
going to actually be easier for people. Maybe I'm misunderstanding.
What are the arguments for separating things -- to make it so people
aren't scared by the number of modules so they'll code? It seems
like some people just want it to be installed and run scripts - does
having them install dozens of modules work. Do we need to consider
people how much this would suck if someone can't use CPAN or
Module::Builder to automate dependancy tracking installation? How
does it work when modules are deprecated?
I'm not sure I have made up my mind on what I'd like to see, but at
some point I think we need to get a clearer idea of what audience we
are trying to serve best. If want it to be easy to install maybe we
should invest time into making OSX double-click installers, RPMs, and
the Windows stuff easily installable. If we want to serve the
developers who aren't using SVN so we want to push out releases of
modules ASAP? I just am not clear on the motivation for some of the
Also - the main point I wanted to make - Can I suggest we spend a
little time discussing what it will take to get a stable release for
the current code as it stands (bioperl-live and bioperl-run)? It
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 assume there is no chance that we'd have a 1.6 candidate by BOSC
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 realize not everyone will be there but
maybe it will be easier to interact on this then.
I think it will also be time to talk with Lincoln/Scott about how
Gbrowse is structured and if that is working for them. There is too
much code in different places that I think we need to figure out how
to structure it properly so those packages can be released. 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
schedules. Also I think someone needs to figure out Bio::Tools::GFF
vs Bio::FeatureIO -- what do we want to do? I don't think we really
fully support GFF3 that well -- the X2GFF scripts probably need some
more good testing (where X is BLAST,FASTA,Sim4, GenBank, EMBL,
etc... ) and or migration to the proper GFF writing.
On Jun 27, 2007, at 7:43 PM, Sendu Bala wrote:
> Chris Fields wrote:
>> On Jun 27, 2007, at 4:05 PM, Sendu Bala wrote:
>>> But the main problem with this approach is that maintenance, global-
>>> style code improvements and releases become a nightmare. I could,
>>> perhaps, imagine a scenario where the repository stayed as-is (one
>>> monolithic collection), but the dist action of Build.PL could be
>>> altered to generate a release package per module instead of one big
>>> release package of all modules, as is currently the case.
>>> Is there much value in doing that? Does anyone want me to look into
>>> the feasibility of such a thing?
>> Not for the time being, at least in my opinion. Too much on our
>> plate at this point with svn migration, test conversion, bugzilla
>> running over (next point of attack!), etc. Maybe something to think
>> about after, though I like the idea of a few splits to core as Steve
>> suggested (SearchIO, Graphics, some LWP-related DB modules).
>> If a fix needed to be made in one set, make the fix, test against
>> bioperl 'base' as a whole, and release when possible. No need to
>> wait for a full-fledged 1.5.3 release.
> What advantage is there of these defined splits instead of individual
> modules? As I see it you lose some of the potential benefits of
> Bioperl up completely, whilst also suffering the maintenance
> problems I
> outlined in my objection to Steve's post.
> Being able to work on all Bioperl from a single cvs (ne svn) check
> archive, whilst distributing it as individual modules on CPAN seems
> the best of both worlds to me. What am I missing?
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
jason at bioperl.org
More information about the Bioperl-l