Some time ago I made the mistake of uploading to CPAN a module called Bio::Tools::Alignment::Overview, the module wasn't associated to bioperl but for some reason I decided to use the namespace anyway (yeah, I know...)
Now I'm organizing some projects and I decided to include the module to bioperl, so if you accept this pull request I will remove from PAUSE/CPAN the current module, so that you can upload it under bioperl.
Sorry for the noobish mistake =)
adding Overview module
adding myself in authors file
adding NextProt module
creating this first methods
adding rest of the methods
adding NextProt POD
making some POD adjustments
removing debug module and adding test file
I just uploaded a new module to deal with the NextProt Database (http://www.nextprot.org). The module is ready and has his own POD. The test file is there but not ready yet. Nevertheless the module seems to be working good.
A small observation, the NextProt test file was not executed by TravisCI, since REST::Client module is missing:
t/RemoteDB/NextProt.t .................. skipped: The optional module REST::Client (or dependencies thereof) was not installed
The module would have to be included on Travis and bioperl dependencies.
finishing test file for NextProt module
Yeah, the prereq should be added to the .travis.yml file. One problem: we are trying to slim down on modules (and dependencies) being added to bioperl-live; could this exist in a separate repo in the bioperl team space? Similar to Florent's Bio-Community?
You mean to use the Bio::* namespace but leave the module outside BioPerl core? Sure! The Bio::Tools::Alignment::Overview module is already published like that, I can do the same with the Bio::DB::NextProt module.
That's basically it. This leaves the core fairly lean, and we can make it leaner by cleaving out other modules with their own dependencies.
OK, sounds great! Fell free to close the pull request.
Do you need help removing modules from the core? is there a list of modules to work somewhere? I could help with this issue.
If the modules are added to core you can go ahead and remove them; if you want to preserve history, there is a nice writeup on the bioperl wiki on how to do this with git (thanks to @carandraug ):
Forgot to mention, @Leprevost if you want to put this under the bioperl namespace we can do that. I can set up the repo and add you to the admins for that repo.
Sounds good. I'm already taking @carandraug directives, looks pretty straightforward (although it takes some time because of the size).
How are you planning to organize the modules outside the core? Do you think its better to have a single repo with all the modules or individual repos for the high-level sections (DB, Align, Ontology, etc) ?
I liked the idea of having separated individual repos, I believe that this way will be more organized and more easily handled by people who wants or need to make changes to the code.
I'm not sure about using checkouts from the core for the submodules, never worked this way. Nevertheless we ca arrange that too you you like.
I picked one module from the Bioperl-live list and I did what the tutorial fro @carandraug tells. The module is Bio::Align::AlignI and its now on this repository (https://github.com/Leprevost/Bio-Align-AlignI). I selected this module because it looked simple enough to see how the migration process is.
Apparently the commit history was ported correctly, i think everything is OK, what do you think?
What should be the next step?
P.S. (happy new year!)
just a reminder.
@cjfields : I locally downloaded this PR, merged it to master and executed the test suite.
The merge produced no conflicts, and all tests (including the ones added in this PR) executed without problems. The only thing is that this module requires REST::Client, so that would need to be added to Build %recommends.
Unless there is another concern, I think this is good to merge. ;)
hey, nice to see some feedback after so long =)
Hi @prvst . I thought the plan was to release it as a separate set of modules to CPAN (see #61 (comment)), hence the long silence. Well, that and I've been ridiculously busy.
I see that it requires REST::Client and GD::Simple, which adds at least two dependencies to the distribution, which is the key problem since we're trying to reduce dependencies in core, a key point to the next release series. We're more than happy to make a new repo for you in the bioperl namespace and set you up with commit rights for that as well as the main repo. Let us know.
I notice that each of the two new pieces of functionality consist of essentially a single module (and file, plus the tests of course), and not because everything's crammed into one file but because they are fairly small and self-contained.
@cjfields I'm wondering what our strategy here is. Having everything in separate modules / packages even if they are exceedingly small is neither a bad one, nor one unheard of - that's basically what the nodeJS ecosystem prides itself for. But are we actually moving to a nodeJS-like strategy? It'd be a rather dramatic (to put it lightly) change from where we're at now.
If the nodeJS-like ecosystem isn't what we're going for, I'm not sure that these two modules warrant their own repositories. They would add to the dependencies, yes, but only optional ones. I.e., by including these we aren't forcing their installation on anyone but those who want to use these modules. I'd be OK with that.
@hlapp The purpose is really to place more power and responsibility with the original developers, both so they can make changes to their own code as well as make independent releases w/o being tied to the BioPerl core module releases.
This doesn't mean they would need to exist independently (they could easily be part of the BioPerl org, so other devs can help contribute and make releases). But I would like to both reduce the maintenance pressure on the core modules, which see infrequent releases, as well as enable others to both participate in the org and take a more direct ownership of their code.
We do have some precedence for this, with the bp-utils and Bio::Community projects, not to mention the BioPerl-network and DB code. Not to mention @lstein code for Gbrowse