bug#17137: autoload-generate-file-autoloads should respect finder--builtins-alist

bug#17137: autoload-generate-file-autoloads should respect finder--builtins-alist

[Glenn Morris]

Package: emacs
Version: 24.3.50

finder.el has finder--builtins-alist to associate directories with packages.
autoload-generate-file-autoloads does not respect this, leading to

  (push (purecopy '(project-am 0 0 3)) package--builtin-versions)

in loaddefs.el, from ede/project-am.el.
This file should be associated with the ede package, per
finder--builtins-alist.

bug#17137: autoload-generate-file-autoloads should respect finder--builtins-alist

[Stefan Monnier]

>   (push (purecopy '(project-am 0 0 3)) package--builtin-versions)
> in loaddefs.el, from ede/project-am.el.
> This file should be associated with the ede package,

Then the file should have a "Package: ede" header.  Or it should not
have a "Version:" header.


        Stefan

bug#17137: autoload-generate-file-autoloads should respect finder--builtins-alist

[Glenn Morris]

Stefan Monnier wrote:

>>   (push (purecopy '(project-am 0 0 3)) package--builtin-versions)
>> in loaddefs.el, from ede/project-am.el.
>> This file should be associated with the ede package,
>
> Then the file should have a "Package: ede" header.  Or it should not
> have a "Version:" header.

As I see it, finder.el has already solved this problem, without
requiring changes in the individual files that make up a package.

Anyway, if you want to solve it the other way, lisp/ede/dired.el also
has a Version header. That one is especially fun, since it would lead to
a version for a "dired" package.

bug#17137: autoload-generate-file-autoloads should respect finder--builtins-alist

[Stefan Monnier]

>>> (push (purecopy '(project-am 0 0 3)) package--builtin-versions)
>>> in loaddefs.el, from ede/project-am.el.
>>> This file should be associated with the ede package,
>> Then the file should have a "Package: ede" header.  Or it should not
>> have a "Version:" header.
> As I see it, finder.el has already solved this problem, without
> requiring changes in the individual files that make up a package.

Then maybe autoload.el could use that same approach.  I know nothing
about it, so I can't judge.

I also remember now that maybe autoload-generate-file-autoloads should
simply use autoload-file-load-name instead of file-name-nondirectory.


        Stefan

bug#17137: autoload-generate-file-autoloads should respect finder--builtins-alist

[Glenn Morris]

Stefan Monnier wrote:

> I also remember now that maybe autoload-generate-file-autoloads should
> simply use autoload-file-load-name instead of file-name-nondirectory.

Can package names contain "/" characters?

Anyway, the easy solution is to remove Version: as you suggested. I
don't think just setting Package: would work, without also setting
Version: to match whatever the actual package version is (because you
would get a random Version: associated with Package: depending on what
order the files were scanned in).

IMO the problem is that "Version" is a very generic header that people
were using before package.el was invented, and now package.el seems to
want complete ownership of it.

But since this autoloads issue only affects things that ship with Emacs,
we can simply fix up the headers as needed.

Perhaps finder-compile-keywords should somehow issue a warning if it
finds a Version: header in the "wrong" file.

bug#17137: autoload-generate-file-autoloads should respect finder--builtins-alist

[Stefan Monnier]

>> I also remember now that maybe autoload-generate-file-autoloads should
>> simply use autoload-file-load-name instead of file-name-nondirectory.
> Can package names contain "/" characters?

Don't see why not.

> IMO the problem is that "Version" is a very generic header that people
> were using before package.el was invented, and now package.el seems to
> want complete ownership of it.

Only for files bundled with Emacs.  That's only a problem for
"sub-packages" (i.e. with a file that's a member of a large package has
its own Version: for some reason).

> Perhaps finder-compile-keywords should somehow issue a warning if it
> finds a Version: header in the "wrong" file.

If we can do that, it would be nice, yes.


        Stefan

bug#17137: autoload-generate-file-autoloads should respect finder--builtins-alist

[Glenn Morris]

Stefan Monnier wrote:

>>> I also remember now that maybe autoload-generate-file-autoloads should
>>> simply use autoload-file-load-name instead of file-name-nondirectory.
>> Can package names contain "/" characters?
>
> Don't see why not.

I'm thinking of things like NAME-readme.txt, where NAME is eg FOO/BAR.
I would not be surprised if package.el starts throwing "No such
directory: FOO" errors. But I haven't bothered to check. A quick glance
shows that it always calls make-directory with PARENTS non-nil, so maybe
it all works out.

bug#17137: autoload-generate-file-autoloads should respect finder--builtins-alist

[Stefan Monnier]

>>>> I also remember now that maybe autoload-generate-file-autoloads should
>>>> simply use autoload-file-load-name instead of file-name-nondirectory.
>>> Can package names contain "/" characters?
>> Don't see why not.
> I'm thinking of things like NAME-readme.txt, where NAME is eg FOO/BAR.

Indeed, the GNU ELPA build scripts will likely fail somewhere with
a foo/bar-NN.MM.el or foo/bar-NN.MM.tar as well, and package.el will
probably burp on those as well.

> I would not be surprised if package.el starts throwing "No such
> directory: FOO" errors.

So, we can have such foo/bar packages bundled with Emacs but we won't be
able to move them out into GNU ELPA, so there's no point having them in
package-builtins.


        Stefan