Can bioboxes and biodocker collaborate on combined objectives? #70

Closed
avilella opened this Issue Feb 27, 2015 · 14 comments

Projects

None yet

4 participants

@avilella

Hi @michaelbarton and @fungs , @pbelmann , @ypriverol, @Leprevost ,

This is a message so that we can all say "hi" to each other and see if
we want to work together on certain aspects or even if we want to
merge our current "bioboxes" and "biodocker" projects into one common
effort: "bioboxers"?? "biodoxes" ??

I can say I know @ypriverol from the EBI, and I would be thrilled if we
would get together to work on this collaboratively. From what I have
seen on the biodocker.github.io website, @Leprevost has already put a lot
of effort in producing containers. I can count about ~25 containers on
the website, also on the hexabio docker hub.

So there is a lot of overlap in what we separately thought would be a
good community-based project. As they say, "brilliant minds think
alike" :-)

@michaelbarton , would it be possible to grant permissions to @ypriverol @Leprevost
and Eduardo (what's his github handle?) to our github group, so they can see what we've been
working on so far?

Cheers,

Albert.

@prvst
prvst commented Feb 27, 2015

Thanks @avilella :)

I like the 'biodocker' style because kinda follows the pattern we see around, like bioperl, biopython, etc. The only problem I see is that the word 'Docker' is also the name of the company, and it kinda feels wrong to use their name on something apart. Maybe we can create something new.

Also, the biodocker project is something completely independent from my company, Hexabio. Initially I hosted on the Hexabio Github page, but for no especial reason. I also like the biobox logo =)

After the project name have being settled, we can come up with some sort of protocol or guidelines to create new images, and how to use the automatic build from docker hub. Usually I create a Dockerfile and host it on Github, after that, through DockerHub, I create a new repo that points out to the Github repo and to create an image. That way, users can just download the existing image instead of building their own.

@avilella

Thanks @Leprevost and welcome 👍

Thanks for clarifying the situation with hexabio, this all sounds good. By the way, are you on Brazil Sao Paulo time? We do a skype call every two weeks, so it should be about early afternoon time for you:

#67

Regarding the guidelines, I am glad you mentioned them, because it's one of the action items that bioboxes wants to have done rather soon. This will give some basic information for people (like me) volunteering to put more bioinformatics apps inside containers.

Also, the idea of writing a paper about the standards and recommendations for bioinformatics containers. We also have something going on in that direction, so I am glad we also coincide with this:

#65

Also @ypriverol , @Leprevost do you plan on going to BOSC 2015 in Dublin this Summer?

Cheers,

@avilella

@michaelbarton michaelbarton changed the title from bioboxes and biodocker to Can bioboxes and biodocker collaborate on combined objectives? Feb 27, 2015
@michaelbarton
Contributor

I've just renamed this issue for clarification.

@prvst
prvst commented Feb 27, 2015

Yes I'm on Sãoo Paulo timezone, we can definitively arrange a Skype/hangouts meeting.

What about bioboxes, it is a nice name, and I see that you already got a domain for it. Is it related to some company or institutional project?

I can also start working on the guidelines and protocols for (creating | reusing) images.

I think that a paper will be great to spread the idea and the use of docker, it hasn't being done so far. I know that the guys from The Assemblathon are using containers to measure tools, but I'm not into the details.

About BOSC, unfortunately I will not be available to go, I'm in the proccess of moving to EUA right now, so I will not have time for it

@michaelbarton
Contributor

Thanks for your input @Leprevost and @avilella. I will add to this discussion
by stating what I believe our immediate objectives are for bioboxes and then
perhaps @pbelmann and @fungs can give their inputs. We can then go from there.

  • Bioboxes will provide a set of standards so that bioinformatics software in
    containers can be used interchangably. A biobox container in a
    bioinformatics pipeline can be swapped with another biobox of the same type
    because they can have the same interface. An example is that a CAMI-created
    biobox can be used in nucleotid.es, and vice versa. #47
  • Bioboxes should provide high quality documentation through the
    specifications documents and on the bioboxes.org website. This
    documentation has two objectives: to make it easy as possible for anyone to
    create a to-spec biobox, and describe how feedback and improvements can be
    provided to the project. #35, #46
  • Following these two objectives above, the bioboxes core team is responsible
    for continual improvement and maintanence of the standards and
    documentation. This will take place through creating, organising and
    resolving github issues. Github pull requests will be used to propose and
    dicuss concrete changes to the specifications. #44

One issue that I raised at the last meeting (#53) is that progress has slowed
down on development of the standard. Specifically in between biweekly meetings
fewer github issues are being resolved. I have tried to resolve this by
categorising the issues better (#64).

I think that a publication is a logical step in the standards process (#45)
however I think this should be done once we have made further progress on the
specs and with agreement from members of the community, for instance large
sequencing centres and journals (#47). I believe the immediate goals should be
getting standards that we at least know we can use ourselves. From my
own work on nucleotid.es I think documentation and validators (#35) are a step
in this direction.

@prvst
prvst commented Feb 28, 2015

Thanks @michaelbarton,

I think we actually exchange some e-mails some time ago.

It seems that you have a lot going on with bioboxes and you are heading somewhere beyond I have planned for biodocker. The idea of having interchangeable containers is very good. My initial plan was to simply have biotools containers, but you guys have a really more robust plan here, and I liked.

Being as it is, maybe the best thing to do is to bring biodockers images to bioboxes, adjusting the images interfaces so that they can follow bioboxes specifications and be independent and interchangeable units. Nevertheless, I'm interested in your project, so if you want, I can help you guys with this.

@avilella

It's great to have you on board, @Leprevost :-)

In my opinion, one of the several definitions of "success" for bioboxes
would be to (1) push as many useful bioinformatics apps inside containers
so they will be readily useful to a lot more people. Having defined
morphisms/interfaces according to (2) specifications, then (3) combining
them with docker combine (fig) and (4) chaining them together in workflows (
github.com/common-workflow-language) will hopefully make these containers
even more useful for people.

I would say reaching 25-50 containers in the area of NGS is very
doable. If we get to 100 by Summer time, I would consider that a
success.

Cheers

On Sat, Feb 28, 2015 at 12:51 PM, Felipe Leprevost <notifications@github.com

wrote:

Thanks @michaelbarton https://github.com/michaelbarton,

I think we actually exchange some e-mails some time ago.

It seems that you have a lot going on with bioboxes and you are heading
somewhere beyond I have planned for biodocker. The idea of having
interchangeable containers is very good. My initial plan was to simply have
biotools containers, but you guys have a really more robust plan here, and
I liked.

Being as it is, maybe the best thing to do is to bring biodockers images
to bioboxes, adjusting the images interfaces so that they can follow
bioboxes specifications and be independent and interchangeable units.
Nevertheless, I'm interested in your project, so if you want, I can help
you guys with this.


Reply to this email directly or view it on GitHub
#70 (comment).

@michaelbarton
Contributor

Thanks for your comments. I think we can use all the input from the
bioinformatics community and your experience @Leprevost with docker is useful.
This project is still very new and so we are shaping it as we go along. My aim
so far has been to try and focus on a limited number of goals at a time so that
we can try and make small incremental progress. Any input you have will be
welcome: examples might be opening issues, creating new specifications,
updating the website or finding typos. I've tried to label some issues as
"E-Easy" as those that should be relatively simple to implement, and could be
one place to start.

@michaelbarton
Contributor

I've updated the website with instructions on how to contribute to bioboxes
(#64, #75).

@michaelbarton michaelbarton reopened this Mar 2, 2015
@pbelmann
Member
pbelmann commented Mar 4, 2015

I think it is a good idea to have more people on board who are familiar with docker.
I agree with @Leprevost that we should define the corresponding interfaces for the biodocker tools and move them to bioboxes. So I think we need first suggestions for interfaces.

@michaelbarton
Contributor

I agree. @Leprevost would you like to propose any new interfaces for containers
you have already written for biodocker?

@prvst
prvst commented Mar 5, 2015

I did not used a pattern or some sort of interface when I did those images, my idea was just to have images for single applications, but this is something we can work on. Is there a definition for a interface container and its objectives? This can be helpful for other in the future as well.

Another thing that can help is a specification for creating a biobox, because we can use different operation systems and configurations inside a container and this can affect how the interface is implemented.

@michaelbarton
Contributor

Discussed in meeting #69. @leprevost has written his interest in participating
in the development of bioboxes. This issue will therefore be closed as
resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment