[Bioperl-l] bioperl executables files and dist-zilla

[Fields, Christopher J]

On Jan 9, 2015, at 11:57 AM, Carnë Draug <carandraug+dev at gmail.com> wrote:
> 
> On 9 January 2015 at 17:12, Fields, Christopher J <cjfields at illinois.edu> wrote:
>> 
>> On Jan 8, 2015, at 6:04 PM, Carnë Draug <carandraug+dev at gmail.com> wrote:
>> 
>>> Hi
>>> 
>>> when installing new bioperl modules with dist zilla, the executable files
>>> are not being installed.  The reason is that our dist zilla plugin bundle [1]
>>> is searching for them in the default directory "bin/" while bioperl seems
>>> to have them in a "scripts/" directory.  This is done by the ExecFiles plugin.
>>> 
>>> I can change this easily or I can just move the binaries to "bin/" (which
>>> I think is more common).  Also, dropping the file extensions would make
>>> things simpler.
>>> 
>>> 
>> 
>> I think in bioperl-live much of the script munging during build/install
>> is handled by the Module::Build sub-class (Bio::Root::Build) but is a bit
>> of a hack; yeah this needs to be migrated to dzil.  Looking at [2] it
>> appears in the role that the directory is settable via the ‘dir’ attribute;
>> would this also be settable during configuration?  The plugin consuming the
>> role is Dist::Zilla::Plugin::ExecDir
> 
> Yes, independently of what we set as default on the PluginBundle, it is
> still possible to have the values changed on a per distribution basis.
> Something like:
> 
>    [@BioPerl]
>    -remove = ExecDir
> 
>    [ExecDir]
>    -dir = scripts

We could leave it as this for now, but in the split out repos use ‘bin’.

>> Alternatively you could move scripts -> bin and symlink ‘scripts’ to point
>> to the new location but I’m not sure how well git handles symlniks.  IIRC
>> it sometimes tries to resolve them.
> 
> I don't think we need to have them symlinked.  We can easily set "scripts/"
> as the default for [ExecDir] on our PluginBundle.  But before we change the
> default, why are we using something which is far less common?  Why are we
> not using "bin/" instead?  If we had the bioperl programs in "bin/" rather
> than "scripts/" we would not have had this problem in the first place.
> 
> So I'm proposing that as we move modules from bioperl-live into the smaller
> distributions, we also move them to a "bin/" directory as part of the
> configuration for dzil (no symlinking required).  This may prevent more
> problems in the future with other tools, by having things where they are most
> expected to be, and not having to remember they are somewhere else.
> 
> By the way, I have already done this on the Bio-EUtilities distribution
> which is where I noticed the problem [1].

Yep, agreed (see above).

>> Re: extensions, I wouldn’t have a problem with this except that old
>> installations of the scripts would still be around, correct? If so, we
>> would need to add a bit of code that checks for the presence of old
>> versions and removes/replaces them.  Might be more trouble than it’s worth.
> 
> Isn't the file extension removed during installation of bioperl?
> I remember that the "bp_" was added automatically, a step which we
> dropped in favour of simply having the files already with the "bp_".
> I thought that it was the same with the file extension.
> 
> Carnë
> 
> [1] https://github.com/bioperl/Bio-EUtilities/commits/master

On our local cluster installation (we have a few default installations packaged up for various tools) the ‘.pl’ is still present.  For example, in our standard base local perl installation (5.16 at the moment):

-system-specific-4.1$ module load perl
-system-specific-4.1$ bp_
bp_aacomp.pl                  bp_fetch.pl                   bp_mutate.pl                  bp_search2table.pl
bp_biblio.pl                  bp_filter_search.pl           bp_netinstall.pl              bp_search2tribe.pl
bp_biofetch_genbank_proxy.pl  bp_flanks.pl                  bp_nexus2nh.pl                bp_seqconvert.pl
bp_bioflat_index.pl           bp_gccalc.pl                  bp_nrdb.pl                    bp_seqfeature_delete.pl
bp_biogetseq.pl               bp_genbank2gff3.pl            bp_oligo_count.pl             bp_seqfeature_gff3.pl
bp_blast2tree.pl              bp_genbank2gff.pl             bp_pairwise_kaks.pl           bp_seqfeature_load.pl
bp_bulk_load_gff.pl           bp_generate_histogram.pl      bp_parse_hmmsearch.pl         bp_seq_length.pl
bp_chaos_plot.pl              bp_heterogeneity_test.pl      bp_pg_bulk_load_gff.pl        bp_seqret.pl
bp_classify_hits_kingdom.pl   bp_hivq.pl                    bp_process_gadfly.pl          bp_seqretsplit.pl
bp_composite_LD.pl            bp_hmmer_to_table.pl          bp_process_sgd.pl             bp_split_seq.pl
bp_das_server.pl              bp_index.pl                   bp_process_wormbase.pl        bp_sreformat.pl
bp_dbsplit.pl                 bp_load_gff.pl                bp_query_entrez_taxa.pl       bp_taxid4species.pl
bp_download_query_genbank.pl  bp_local_taxonomydb_query.pl  bp_remote_blast.pl            bp_taxonomy2tree.pl
bp_einfo.pl                   bp_make_mrna_protein.pl       bp_revtrans-motif.pl          bp_translate_seq.pl
bp_extract_feature_seq.pl     bp_mask_by_search.pl          bp_search2alnblocks.pl        bp_tree2pag.pl
bp_fastam9_to_table.pl        bp_meta_gff.pl                bp_search2BSML.pl             bp_unflatten_seq.pl
bp_fast_load_gff.pl           bp_mrtrans.pl                 bp_search2gff.pl
-system-specific-4.1$ which bp_einfo.pl
/home/groups/hpcbio/perllib/perl-5.16.1/bin/bp_einfo.pl

chris