bioperl executables files and dist-zilla

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

bioperl executables files and dist-zilla

Carnë Draug-2
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.

One last thing, I was thinking of adding the SetScriptShebang plugin [3]
to the bundle. Opinions?

Carnë

[1] https://metacpan.org/pod/Pod::Weaver::PluginBundle::BioPerl
[2] https://metacpan.org/pod/Dist::Zilla::Role::ExecFiles
[2] https://metacpan.org/pod/Dist::Zilla::Plugin::SetScriptShebang

_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bioperl executables files and dist-zilla

Fields, Christopher J
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

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.

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.

chris

On Jan 8, 2015, at 6:04 PM, Carnë Draug <[hidden email]> 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.
>
> One last thing, I was thinking of adding the SetScriptShebang plugin [3]
> to the bundle. Opinions?
>
> Carnë
>
> [1] https://metacpan.org/pod/Pod::Weaver::PluginBundle::BioPerl
> [2] https://metacpan.org/pod/Dist::Zilla::Role::ExecFiles
> [2] https://metacpan.org/pod/Dist::Zilla::Plugin::SetScriptShebang
>
> _______________________________________________
> Bioperl-l mailing list
> [hidden email]
> http://mailman.open-bio.org/mailman/listinfo/bioperl-l


_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bioperl executables files and dist-zilla

Carnë Draug-2
On 9 January 2015 at 17:12, Fields, Christopher J <[hidden email]> wrote:

>
> On Jan 8, 2015, at 6:04 PM, Carnë Draug <[hidden email]> 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

> 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].

> 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

_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bioperl executables files and dist-zilla

Fields, Christopher J
On Jan 9, 2015, at 11:57 AM, Carnë Draug <[hidden email]> wrote:

>
> On 9 January 2015 at 17:12, Fields, Christopher J <[hidden email]> wrote:
>>
>> On Jan 8, 2015, at 6:04 PM, Carnë Draug <[hidden email]> 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


_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: bioperl executables files and dist-zilla

Carnë Draug-2
On 9 January 2015 at 18:33, Fields, Christopher J <[hidden email]> wrote:

> On Jan 9, 2015, at 11:57 AM, Carnë Draug <[hidden email]> wrote:
>>
>>
>> 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).
>> [...]
>>
>
> Yep, agreed (see above).

Seems like I already knew this before since I fixed that for Bio-Biblio
almost 2 years ago [1].

I have just changed this on Bio-FeatureIO, Bio-SearchIO-Writer-BSMLResultWriter,
and Bio-Community.

>>> 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
> [...]

You are right. I only install bioperl-live from the repositories (Debian), so
I never noticed that it was Debian's doing.  Checking Debian's diff [2], I now
see:

    +    # prename is the rename utility written in perl usually
available as /usr/bin/rename in Debian.
    +    prename s/.pl$$// debian/bioperl/usr/bin/*pl
    +    prename s/.pl.1p$$/.1p/ debian/bioperl/usr/share/man/man1/*1p

Why the extension once installed? That seems very uncommon.  Just running
`grep -lP '^#!.*perl' /usr/bin/*` shows several but none have a file
extension. Same for python and sh, the executables do not typically keep
the file extension of the language they are written on.

Carnë

[1] https://github.com/bioperl/Bio-Biblio/commit/cbe34d52696d9157d71c853ef96849d455fcc780
[2] http://ftp.de.debian.org/debian/pool/main/b/bioperl/bioperl_1.6.1-2.diff.gz

_______________________________________________
Bioperl-l mailing list
[hidden email]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l
Loading...