[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: package autoload
From: |
Oliver Heimlich |
Subject: |
Re: package autoload |
Date: |
Sat, 16 Apr 2016 22:53:41 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 |
On 16.04.2016 19:43, PhilipNienhuis wrote:
> Oliver Heimlich wrote
>>
>> <snip>
>> Removal of autoload will (hopefully) have one big advantage: That people
>> add “pkg load” commands at the beginning of their script files. This
>> will make the script files portable(*) and other users can easily tell
>> that they miss a particular package if the script stops right at the
>> start on their computer.
>
> That would be great if at the end of that script file the package is
> unloaded as well.
> I'm not fond of scripts that manipulate environments w/o cleaning up
> afterwards (unless such environment changes are intended for regular
> operation of SW).
>
> Maybe a sort of "local"switch is required that loads packages only in the
> scope of functions and automatically unloads them at function exit.
Script files and function files are different. Also I find loading the
package more important than unloading (unless you have a package that
overrides and thereby breaks stuff).
Please note that the -local switch is already implemented but does
something different. Loading and unloading packages as part of a
function call has the potential to become a messy thing as well.
>> I find this particularly important in scientific publications when you
>> can easily tell from a script which packages the author has intended to
>> use. Compare this with other languages where you have
>> import-/use-statements for functions that your source code uses (and you
>> need in your namespace).
>
> Hmmm, looks a bit like a niche problem to me.
> While you might see what packages are used you still can't see which
> versions.
> IMO it's more a peer reviewer's job to check for completeness of code
> snippets.
The idea is that you can copy and run shared scripts easily. It does not
depend on a “pkg load” command in your startup files, which might have
been present at the developer's computer.
The version is not so much a problem: First, the author should have
cited the particular version used. Second, unless the package goes
through compatibility breaking changes you can still run the script with
a newer / the latest version of a package.
Oliver
P.S. Philip, your nameserver seems to be down. I can't answer you
directly. Hopefully you find this message in the mailing list.
- package autoload, Olaf Till, 2016/04/15
- Re: package autoload, Juan Pablo Carbajal, 2016/04/15
- Re: package autoload, Ben Abbott, 2016/04/15
- Re: package autoload, LachlanA, 2016/04/15
- Re: package autoload, oheim, 2016/04/15
- Re: package autoload, Olaf Till, 2016/04/15
- Re: package autoload, LachlanA, 2016/04/16
- Re: package autoload, Olaf Till, 2016/04/16
- Re: package autoload, PhilipNienhuis, 2016/04/16
- Re: package autoload,
Oliver Heimlich <=
- Re: package autoload, PhilipNienhuis, 2016/04/17
- Re: package autoload, Ben Abbott, 2016/04/15
- Re: package autoload, Juan Pablo Carbajal, 2016/04/15