Philip Kaludercic <philipk@posteo.net> writes: > Björn Bidar <bjorn.bidar@thaodan.de> writes: > >>>>>> For example Borg only works because of magit, epkg is almost useles >>>>>> without Borg. >>>>> >>>>> Just to clarify, I have never used Borg, straight, elpacaa, etc. so I >>>>> don't know how they work, how they are used or what terminology they >>>>> use. I have peeked into their source code in the past, but none of that >>>>> was related to the development of package-vc. >>>> >>>> That's to bad I think it very helpful to improve on such packages or >>>> even just adapt them instead of reinventing them. >>> >>> The point of package-vc.el is to have something that explicitly extends >>> package.el and works in the core, in active collaboration with ELPA. >>> That is why the implementation is far simpler than what others have to >>> do, because they are fighting an up hill battle outside of the core. >> >> There might be reasons for that.. >> Quite often the core packages aren't as good or just to >> complicated/convoluted with legacy features. > > My experience has been quite the opposite -- I wouldn't be a > more-or-less-regular contributor if that weren't my impression. Core > packages are usually developed by people with a good sense of what makes > Emacs "Emacs". That seems to be really subjective a lot people use Emacs but wouldn't without Melpa and co. Core packages often lack a lot of modern features. But a lack of features can be a feature too thou. > Most of the time the complexity you speak of has an explanation, even if > that explanation is only due to the responsibilities of having a package > in core. > >> Or in case of borg compared to package-vc deeper integration into git or >> other different features like building packages in a second instance >> with just borg and the package. > > Right, that is an advantage that Borg has by /committing/ to Git, > instead of going through VC and avoiding a strict dependency on one > specific VCS. Which makes it by design less reproduceable unless it vc keeps track of all the version control information like last ref of that package and its source. But I assume that's what's done here. Something like make bootstrap could be very useful e.g. to use your configuration on another machine, so that emacs can start after all packages needed in init.el are present. https://emacsmirror.net/manual/borg/Using-your-configuration-on-another-machine.html Br, Björn
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4