[Bioperl-l] Bb-utils

Tue Dec 16 18:10:57 UTC 2014

Weigang,

Added these in. You can follow the directions on the github repo link to push up the repository whenever you’re ready (you should have full admin on that repo).

chris

On Dec 15, 2014, at 4:39 PM, Weigang Qiu <weigangq at gmail.com<mailto:weigangq at gmail.com>> wrote:

Hi, Chris,

I just signed up for github with the username "weigangq". One of my team member is Girish Ramrattan <gramratt at gmail.com<mailto:gramratt at gmail.com>> with the username "gramratt3"

thanks for your facilitation,

On Mon, Dec 15, 2014 at 3:01 PM, Fields, Christopher J <cjfields at illinois.edu<mailto:cjfields at illinois.edu>> wrote:
Weigang,

Probably will be named ‘bp-utils’, though this can be changed:

https://github.com/bioperl/bp-utils

Just to make sure, what is your Github ID (along with anyone else from your lab contributing to it)?  I can add a team for that repo.

chris

On Dec 15, 2014, at 1:49 PM, Weigang Qiu <weigangq at gmail.com<mailto:weigangq at gmail.com>> wrote:

Pablo, Chris, and George,

I'm glad to know that there are other similar ongoing efforts & this may grow into a joint project. (I agree that many commonly-used methods are better refactored back into API.)

Thanks for the ideas and support. It would be great if some of you could set up a broadly themed, developer-enticing repo ("bputils", "bioutils", "user-supplied utilities", "workflow tools", ?) and wiki page under bioperl so we could proceed to fill the content.

Thanks & best,

weigang

On Sun, Dec 14, 2014 at 2:30 PM, Fields, Christopher J <cjfields at illinois.edu<mailto:cjfields at illinois.edu>> wrote:
It’s ‘approved' :)

Easy enough to set up a repo within the bioperl space for this and grant permissions to whomever (just need a github account).  We just need a name for the repo.

We can also set up a wiki presence on http://bioperl.org<http://bioperl.org/>, but we’ve been discussing (off-list) using the GitHub wiki (or readthedocs) and setting up a GitHub Pages portal for projects:

https://help.github.com/articles/user-organization-and-project-pages/

This might may be a good place to start such an initiative.

chris

On Dec 13, 2014, at 11:48 PM, Weigang Qiu <weigangq at gmail.com<mailto:weigangq at gmail.com>> wrote:

Hi, George, Chris, and Cacau:

That's my question as well: these are bp wrappers and utility scripts, not APIs that fits into CPAN naturally. I have an informal source-forge repository for bp-utils, but not quite ready for form formal release.

My intention of having it somehow housed within bioperl is not only for exposure and attracting usage and development, but also to pay proper tribute to you guys' hard work maintaining and developing bioperl.

I appreciate the suggestion of having its own name space. If approved, I (and my lab members) will make sure it doesn't not fall into poor maintenance and being an orphan. Having a wiki presence may be a good first step to gradually and properly roll it out?

thanks,

On Sat, Dec 13, 2014 at 11:12 PM, Fields, Christopher J <cjfields at illinois.edu<mailto:cjfields at illinois.edu>> wrote:
On Dec 13, 2014, at 3:11 PM, George Hartzell <hartzell at alerce.com<mailto:hartzell at alerce.com>> wrote:

> Fields, Christopher J writes:
>> Hi Weigang,
>>
>> I wonder whether it would be better to have a separate bputils repo
>> in the BioPerl space.  This would allow development to continue w/o
>> tying it directly to a release, and I think would solve the
>> exposure problem much more so than having it included in the main
>> bioperl-live repo.  We could also feasibly include it as part of
>> the main CPAN bioperl release, maybe by simply linking to it as a
>> git submodule and packaging it up.
>> [...]
>
> Given how hard you've been working to break things out of the core and
> keep orphan things that *are* in core working, I'd suggest that there
> would have to be a really pressing technical reason (and longterm
> support commitment) to include the the main CPAN release.
>
> Seems *way* cleaner to wrap it up into it's own CPAN release, give it
> a good, evocative name, and make sure the distribution is well built
> (correct meta info, dependencies, etc...).
>
> Then it'll be easy to find, easy to install and will not increase the
> support burden of the core (or complicate the ongoing cleanup).
>
> Errr, wait.  Someone *did* ask what I thought, didn't they? :)
>
> g.

Yes to all of this :)

My only question would be, are there a lot of distributions that consist primarily of scripts that rely completely on another distribution?

chris

--
Weigang Qiu (邱伟刚)
117-14 Union Turnpike
AC3
Kew Gardens, New York 11415
1-917-678-3301<tel:1-917-678-3301>

--
Weigang Qiu (邱伟刚)
117-14 Union Turnpike
AC3
Kew Gardens, New York 11415
1-917-678-3301<tel:1-917-678-3301>

--
Weigang Qiu (邱伟刚)
117-14 Union Turnpike
AC3
Kew Gardens, New York 11415
1-917-678-3301

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/bioperl-l/attachments/20141216/6360ef4a/attachment.html>