Re: package autoload

[PhilipNienhuis]

Oliver Heimlich wrote
> 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).

"breaks stuff" is exactly my "gripe".
E.g., shadowing functions (core, package or one's own functions) is an
example.

I'm a fan of cleaning up after the work is done.  Like many other people I
wasn't quite born that way, I had to learn the hard way later in life :-) 

BTW, many many Matlab scripts I've seen start with "clear all; close all;". 
For Octave that would imply to also include "pkg unload all".


> Please note that the -local switch is already implemented but does
> something different.

That's why I double-quoted it. 
I should have been more specific, i.e. comparing it to the "local" switch in
warnings
But I think the intention is clear.


> Loading and unloading packages as part of a
> function call has the potential to become a messy thing as well.

Unless it is the "outer"one where everything needed for some special
application could be set up and initialized in the scope of that function
and its descendants.
(and cleaned up afterwards, but that doesn't seem popular)


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

So then you also know what packages the author used, no?

Anyway, I do not disagree with your intention at all; for a scientific -and
thus specialized- applications, and for other specialized situations like
testing, your suggestion is helpful.
But bluntly advising to always add "pkg load" commands to every script file
(that is the way I read your argument) can make for a messy situation later
on. I'd be more careful with such advice.


> P.S. Philip, your nameserver seems to be down. I can't answer you
> directly. Hopefully you find this message in the mailing list.

I posted through nabble as I am not subscribed to any Octave mailing list.
Heaven knows how nabble links my email address to thread postings, but
usually it does a good job once I posted.

nabble does have a few quirks though (e.g., the irritating super-resume
pop-up that even avoids uBlock-origin).

Thanks,

Philip




--
View this message in context: 
http://octave.1599824.n4.nabble.com/package-autoload-tp4676287p4676343.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.