emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Easy configuration of a site-lisp directory


From: Arthur Miller
Subject: Re: Easy configuration of a site-lisp directory
Date: Thu, 26 Aug 2021 17:58:00 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Philip Kaludercic <philipk@posteo.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> I think that something like what you propose is OK for you who are developer 
>> and
>> know what you do. But if you put something like this on auto in Emacs, I 
>> think
>> that lots of people with get troubles which can lead to even more frequent 
>> mailing
>> list :).
>
> I guess this depends on whether or not this would be enabled by default
> or not. My suggestion uses ~/.emacs.d/site-lisp by default if it
> exists. I get what you mean that this might be an issue, so it something
> like this could (and probably should) be disabled by default, but easy
> to activate.
>
>>> If there is some critical change or something that isn't ready yet, I'd
>>> just use "git stash".
>>>
>>>> What you are suggesting is to effectively use "site-lisp" as another
>>>> package-user-dir (~/.emacs.d/elpa on my machine). You are also auto
>>>> recursing in all dirs, so if user wish to remove something they have to
>>>> remove that directory from the path?
>>>
>>> Yes, but I hesitate to compare it to package-user-dir, as to me packages
>>> stand in relation to some package manager, while site-lisp.el only
>>> implements the bare minimum.
>>
>> Exactly. I am not sure if it is even the bare miniumum. 
>>
>> Bringing in paths and code in Emacs, is just but one part of package
>> management. Installling dependencies and also uninstalling everything 
>> correctly,
>> not leaving orphaned pacakges behind or removing something still needed is as
>> important as well. For that reason I think that going through package.el 
>> would
>> be a better idea.
>
> I think I agree. package-list-packages already lists different
> package states (available, installed, built-in, ...) so it might also
> make sense to have a "local" package as well.
>
>> Everyone's setup is of course private, but I don't think that is a 
>> good idea and good alternative to proper package management. For the same 
>> reason
>> why we don't install packages manually in our gnu/linux distributions but use
>> some sort of package management system. Doing manually ./configure - make 
>> dance
>> is nowdays considered a bad practice.
>
> I'm not sure, it depends on what you are doing. package managers usually
> don't expect the user to change the software that has been
> installed. You usually only get a binary version and any modification
> will be overridden. If you want to work on some software, and actually
> use your software freedom, you have to do the ./configure-make-dance.

Of course, but usually number of packages one works on and number of installed
packages is not as nearly as same. I do run Emacs form the source dir. But Emacs
and few others are excpetion.

> I'm not sure, it depends on what you are doing. package managers usually
> don't expect the user to change the software that has been
> installed. You usually only get a binary version and any modification
> will be overridden. 

Yes, so it is, and that does not really suit package development in Emacs.
So we would probably need something that goes well with development. 

I think that times have have changed, git and web service indeed has
revolutinionized the way people, share and contrubute with each other. Also
hackability of Emacs and lisp are a bit unique. So we probably need something
that works well with git, at least for now (nothign says git is given for all
times).

What about having something like 'package-install-dev' which will install dev
sources, git repo and do what Stefan suggested he does in elpa-adming.el?

Of course could be options to install all packages as 'dev', or have a list of
'dev' or some other way to controll this automatically.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]