bugGNU Octave - Bugs: bug #47658, remove autoload feature of packages

 
 

bug #47658: remove autoload feature of packages

Submitter:  Carnë Draug <carandraug>
Submitted:  Sun 10 Apr 2016 11:10:56 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 14 Apr 2016 02:19:06 PM UTC, comment #6: 


> The following comments may be slightly off-topic, but their gist is to say that I think dropping the current method of auto loading is a good idea.
>
> I think that some degree of loading on demand is still feasible and desirable. [...]
> [...]
> I'd be interested in your thoughts, even if you still think my suggestions are a very bad idea :)


That is indeed out-of-topic since that addresses loading packages at runtime as they are needed while this bug is only about automatic package loading at start time.

The type of thing you suggest is the type that should be done explicitly. What will happen for example when you have two packages with functions with same name? I get it that the concept of packages seems to still confuse some users.  We already give error messages reminding them to load a package and I think this has worked well to reduce the number of help requests about forgetting to install and load packages.  I don't know what else we can do about it and I'm not sure we should be doing anything either.  (if you want to discuss this, it's better on the mailing list or another bug report but this sounds like a really bad idea).

Anyway, since no opposed the original patch, I rebased it and pushed it http://hg.savannah.gnu.org/hgweb/octave/rev/cf227735d5fd  (I forgot to amend the commit message to point to this bug number) :/

Carnë Draug <carandraug>
Group Member
Tue 12 Apr 2016 11:23:10 AM UTC, comment #5: 

Carnë, thanks for the explanation in comment #2.  The following comments may be slightly off-topic, but their gist is to say that I think dropping the current method of auto loading is a good idea.

I think that some degree of loading on demand is still feasible and desirable.  Currently, if a package is installed but not loaded, and a function from that package is called, then an error is issued that tells the user which package to load.  In the cases where Octave knows which package to load, it seems sensible (IMHO) for Octave just to go ahead and load it rather than throwing an error.  If there is ambiguity, then by all means throw an error.

That doesn't cause the problems with overloaded functions (since the core version is found if the package hasn't been loaded) and doesn't cause conflicts unless the user actually calls two functions from conflicting packages.  It just means that a lot more scripts "just work" without the user needing think about packages.

I can see three disadvantages:
0. The user may accidentally load a package by a typo.  That's no big problem, especially if a warning is given when a package is loaded on demand.
0. The user may wonder why changing the order of two function calls changes the behaviour of one of them, in the case of a shadowed function being called before or after another function from the package.  Again, this isn't a problem if a warning is given to remind the user that the package is being loaded.
0. The user may find this so simple that they don't bother learning how to use the package manager to, for example, unload one package before loading a conflicting package.  IMHO, if the user can use the system without needing to learn how the package manager works, that is a benefit.  It also aids Matlab compatibility to have a script that doesn't need "pkg <...>" statements.

I'd be interested in your thoughts, even if you still think my suggestions are a very bad idea :)

Lachlan Andrew <lachlan>
Mon 11 Apr 2016 06:54:58 PM UTC, comment #4: 


> Is there really an OF package called "auto"? If so it makes me wonder what it does.


No, as far as I know there is none.

> AFAIU package dependencies are also kept in the octave_packages file. Is that info still required, if so available, anywhere else? I can imagine that package A depending on package B would like to "know" if B is loaded before A.


You're right, I forgot that :/

Carnë Draug <carandraug>
Group Member
Mon 11 Apr 2016 06:44:41 PM UTC, comment #3: 

This cset aims for simplification, which is usually Good.

Is there really an OF package called "auto"? If so it makes me wonder what it does.

AFAIU package dependencies are also kept in the octave_packages file. Is that info still required, if so available, anywhere else? I can imagine that package A depending on package B would like to "know" if B is loaded before A.

Philip Nienhuis <philipnienhuis>
Group Member
Mon 11 Apr 2016 05:43:38 PM UTC, comment #2: 


> Could someone explain the rationale for the current load mechanism?


I'm not sure what's your question. Some packages can set themselves to autoload during install. If they do so, the package will load itself when Octave starts. However, packages automatically loading themselves are a bad idea; it should be the user that loads them explicitly (or "automatically" in octaverc).  See http://wiki.octave.org/FAQ#How_do_I_automatically_load_a_package_at_Octave_startup.3F

There is no recent Octave Forge package that makes use of autoload (this has nothing to do with autoload() for oct files, I am only talking about package autoload).

> IMHO, it would be sensible for the functions of all installed packages to be available (i.e., on the path, using "addpath(genpath ())") at boot, and that any .oct files should be linked on demand, rather than requiring all .oct files for a given package to be loaded at once.


No, we do not want to load all packages automatically. We have been there before.  It ends with users annoyed about weird Octave because they loaded packages that incompatible or change how octave core works.  See http://wiki.octave.org/FAQ#How_do_install_or_load_all_Octave_packages.3F

Carnë Draug <carandraug>
Group Member
Mon 11 Apr 2016 04:37:29 AM UTC, comment #1: 

This sounds more like a request-for-comment than a bug.

Could someone explain the rationale for the current load mechanism?

IMHO, it would be sensible for the functions of all installed packages to be available (i.e., on the path, using "addpath(genpath ())") at boot, and that any .oct files should be linked on demand, rather than requiring all .oct files for a given package to be loaded at once.

Lachlan Andrew <lachlan>
Sun 10 Apr 2016 11:10:56 PM UTC, original submission:  

The attached cset removes pkg support for autoloading of packages.  This has the following positive impacts:

  • default octave startup is faster (because it does not run 'pkg load auto').  Not by much though, 90% of previous time.
  • unblocks fix for another bug which prevents a package from being named auto.
  • we no longer have to fix generate_html to guess the default autoload.
  • pkg becomes simpler (this cset only removes code).
  • reduces need for an octave_packages file (ideally we would not need such file and be able to deduce everything quickly from filepaths -- the remaining issue is the version number on the package directory name but I'll address that after this change).


This has the following negative impact:

  • user can no longer install packages with the auto option.


Octave Forge packages no longer autoload by default.  In addition, the general recommendation has been to use package specific 'pkg load' commands in octaverc so hopefully the impact will be minimal.

Carnë Draug <carandraug>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #36890:  remove-pkg-autoload.cset added by carandraug (11KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by carandraug (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-14 carandraug StatusNone Fixed
        Open/ClosedOpen Closed
    2016-04-10 carandraug Attached File- Added remove-pkg-autoload.cset, #36890

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code