Re: package-get.el : package-get-user-package-location
sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes:
Is no more in 21.2.
>> >> The general concept of having a single package hierarchy
>> >> into which user packages go is broken by now.
Jan> Huh? Why?
There are *two* now under ~/.xemacs: xemacs-packages and
mule-packages.
Yes. And this one is a definite candidate for ~/.xemacs/site-packages ....
>> Especially the latter is totally sloppy and should be
rewritten.
Jan> Please define 'sloppy'.
There's no clear concept of where the package index is really supposed
to go. `package-get-locate-index-file' calls `locate-data-file', but
the location where the package index is *stored* is not inferred from
`data-directory-list' at all.
Ok, the problem here is that the directories in data-directory-list
can magically appear. There maybe no ~/.xemacs/etc/ directory now but
(in 21.1) it will magically appear if we create it and restart XEmacs.
Moreover, `package-get-locate-index-file', as a last resort,
just
returns `package-get-base-filename' without checking for its
existence.
Ok, granted. I think this cruft left from earlier versions.
Jan> Please define broken? It al does what it is supposed to
(modulo "~")
Jan> 4. If we cannot write to it, offer to write it to a location
where the
Jan> user is likely to be able to write and where XEmacs will find it
Jan> again (i.e. the etc directory of the users package hierarchy).
But there's a strange mixture of genericity (`locate-data-file') and
hard-wired path construction (like (expand-file-name "etc/"
package-get-user-package-location) ) going on.
Yes, but it is necessary because of the "magic" creation problem and
the fact that we really want to stick in the top level /etc directory
of a package hierarchy, not the "etc/" of some package.
Jan