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: Philip Kaludercic
Subject: Re: Easy configuration of a site-lisp directory
Date: Thu, 26 Aug 2021 09:42:50 +0000

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.

> Anyway, I understand your attempt, and I responded, because I was lately
> looking for myself what to do, becuase I also would prefer to have easy 
> hackable
> packages, with same consideration as you said, to have emacs help system and
> xref bring me to correct spot. I am not sure myself what I am gonna use.

-- 
        Philip Kaludercic



reply via email to

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