<div dir="ltr"><div>Hi, George, Chris, and Cacau: <br></div><div><br>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.<br><br>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.<br><br></div><div>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?<br><br></div><div>thanks,<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 13, 2014 at 11:12 PM, Fields, Christopher J <span dir="ltr"><<a href="mailto:cjfields@illinois.edu" target="_blank">cjfields@illinois.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Dec 13, 2014, at 3:11 PM, George Hartzell <<a href="mailto:hartzell@alerce.com">hartzell@alerce.com</a>> wrote:<br>
<br>
> Fields, Christopher J writes:<br>
>> Hi Weigang,<br>
>><br>
>> I wonder whether it would be better to have a separate bputils repo<br>
>> in the BioPerl space. This would allow development to continue w/o<br>
>> tying it directly to a release, and I think would solve the<br>
>> exposure problem much more so than having it included in the main<br>
>> bioperl-live repo. We could also feasibly include it as part of<br>
>> the main CPAN bioperl release, maybe by simply linking to it as a<br>
>> git submodule and packaging it up.<br>
>> [...]<br>
><br>
> Given how hard you've been working to break things out of the core and<br>
> keep orphan things that *are* in core working, I'd suggest that there<br>
> would have to be a really pressing technical reason (and longterm<br>
> support commitment) to include the the main CPAN release.<br>
><br>
> Seems *way* cleaner to wrap it up into it's own CPAN release, give it<br>
> a good, evocative name, and make sure the distribution is well built<br>
> (correct meta info, dependencies, etc...).<br>
><br>
> Then it'll be easy to find, easy to install and will not increase the<br>
> support burden of the core (or complicate the ongoing cleanup).<br>
><br>
> Errr, wait. Someone *did* ask what I thought, didn't they? :)<br>
><br>
> g.<br>
<br>
</div></div>Yes to all of this :)<br>
<br>
My only question would be, are there a lot of distributions that consist primarily of scripts that rely completely on another distribution?<br>
<br>
chris</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Weigang Qiu (邱伟刚)<br>117-14 Union Turnpike<br>AC3<br>Kew Gardens, New York 11415<br>1-917-678-3301</div>
</div>