Re: package autoload

[Oliver Heimlich]

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.