future of burrito?

[biocore]

future of burrito?

[wasade]

@RNAer has been doing some very cool replacement work with dumpling...

[ElDeveloper]

From an email I sent to the qiime-developers ML:

Hello,

Rob, Jose N, Antonio, Zech, Jamie and me talked about using Dumpling, as
a replacement of burrito, these are a few points we would like to
highlight.

Dumpling has the following advantages:

1. Saves boiler-plate code when writing fillings.

2. "Cleaner" design, especially for app parameters.

   1. condense all burrito param types into 2 types: argument and option, as defined in linux command and explained by click doc (http://click.pocoo.org/6/parameters/)

   2. users can give a semantic, meaningful name to a parameter, making code more readable in the context of the app wrapped.

   3. the parameter name can be passed as keyword argument to a function directly to set the parameter of a wrapper. This is critical, because you can easily pass the same variable, for example, the number of cpu cores, to functions calling different apps.

   There are other improvements, like you don't need to wrap a file
   path in quotes like you do in burrito. etc.

3. Uses subprocess (with shell=False), instead of os.system to call the executables, which is more secure. And user don't need to worry about the weird characters in the parameter.

4. Better documentation and tests. numpydoc string doc. doctests illustrates examples of frequent use cases.

Dumpling, has a few big differences compared to Burrito:

1.- Applications are all instances of the same class, except with different parameters. This can be problematic from the point of view of a "dumpling filling", the exposed API/object is an instance, not a class. This problem, however can be circumvented if a bit of the API in the Dumpling class is changed, or if we use "factory" wrappers that act like classes.

2.- One of the reasons why it was hard to use Burrito, was the lack of an update method, this method is available in Dumpling, so maybe adding it to Burrito would be a good thing to consider doing if we were to keep some of that code around.

For a concise example, please have a look at the notebook below where you can see a side by side comparison of the implementation of a

https://github.com/RNAer/dumpling/blob/master/examples/dumpling_burrito.ipynb

Thanks!

[RNAer]

if the decision is to move forward with dumpling code base, I can take over
the primary role of maintainer if nobody else volunteers.

On Wed, May 4, 2016 at 9:37 AM, Yoshiki Vázquez Baeza <
[email protected]> wrote:

From an email I sent to the qiime-developers ML:

Hello,

Rob, Jose N, Antonio, Zech, Jamie and me talked about using Dumpling, as

a replacement of burrito, these are a few points we would like to

highlight.

Dumpling has the following advantages:

Saves boiler-plate code when writing fillings.
2.

"Cleaner" design, especially for app parameters.

1. condense all burrito param types into 2 types: argument and option,
   as defined in linux command and explained by click doc (
   http://click.pocoo.org/6/parameters/)

2. users can give a semantic, meaningful name to a parameter, making
   code more readable in the context of the app wrapped.

3. the parameter name can be passed as keyword argument to a function
   directly to set the parameter of a wrapper. This is critical, because you
   can easily pass the same variable, for example, the number of cpu cores, to
   functions calling different apps.

There are other improvements, like you don't need to wrap a file

path in quotes like you do in burrito. etc.
3.

Uses subprocess (with shell=False), instead of os.system to call the
executables, which is more secure. And user don't need to worry about the
weird characters in the parameter.
4.

Better documentation and tests. numpydoc string doc. doctests
illustrates examples of frequent use cases.

Dumpling, has a few big differences compared to Burrito:

1.- Applications are all instances of the same class, except with
different parameters. This can be problematic from the point of view of a
"dumpling filling", the exposed API/object is an instance, not a class.
This problem, however can be circumvented if a bit of the API in the
Dumpling class is changed, or if we use "factory" wrappers that act like
classes.

2.- One of the reasons why it was hard to use Burrito, was the lack of an
update method, this method is available in Dumpling, so maybe adding it to
Burrito would be a good thing to consider doing if we were to keep some of
that code around.

For a concise example, please have a look at the notebook below where you
can see a side by side comparison of the implementation of a

https://github.com/RNAer/dumpling/blob/master/examples/dumpling_burrito.ipynb

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#16 (comment)

[gregcaporaso]

I sent this by email this morning in response to @ElDeveloper: I'm fine with you guys making the switch. I can add a note to burrito/burrito-fillings that the packages are in "maintenance mode" (no new features, just bug fixes that are relevant for legacy packages that depend on it, like QIIME 1). Let me know if you guys want me to do this.