Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Continuous integration for el-get packages #2869

Open
elliottslaughter opened this issue Aug 16, 2022 · 6 comments
Open

Continuous integration for el-get packages #2869

elliottslaughter opened this issue Aug 16, 2022 · 6 comments

Comments

@elliottslaughter
Copy link

I dread reinstalling my el-get setup, because it seems like every time I try, one or more packages are inevitably broken. Today, it was undo-tree, a couple months back it was org-mode, and there are many others I'm sure I've forgotten over the years. Commonly used packages tend to get fixed eventually, but "eventually" is long enough that, like I said, inevitably something is broken every time I reinstall.

This issue is not about any specific package, but about the process: is it time perhaps to set up a CI for el-get packages, as opposed to just el-get itself? It doesn't need to be often, but something that can run once a day (ish) and report package installation failures would go a long way towards correcting issues in the ecosystem. And if a package is breaking repeatedly then that may indicate a low-quality or understaffed project that perhaps should be reconsidered in the el-get package database.

@lispstudent
Copy link
Contributor

Same here.

I am a fan of el-get. It is simply the best, according to my use-case. I won't change it with any other package handler. But often things are not smooth as they could.

They way I fix potential issues with packages on my side is to cull my own small curated el-get package "repo", so that at least I kind of know where to look.

But, for example, I cannot recommend el-get to fellow students, as it can be very soon a road block to using Emacs, instead of a trusty sidekick.

@dimitri
Copy link
Owner

dimitri commented Aug 18, 2022

Hi @elliottslaughter and @lispstudent ; thanks for those comments!

One key design choice I made with el-get is this idea of distributed recipe handling. I didn't want to design a central place for recipes like MELPA is, even though a central place allows for curating the recipe list. Maybe what could be done now is a concept of an el-get distribution, and we could build a first curated distribution of tested el-get recipes?

I can't remember the details and implementation of el-get, it might be that the code already deals with such a distribution concept, but I'd be surprised. Who wants to work on that and contribute this features, and then who wants to create, curate, and maintain a quality stable distribution for el-get?

@lispstudent
Copy link
Contributor

@dimitri Thank you for reading and replying to this ticket.

To be frank, you are one of my Common Lisp heroes, for the wonderful pgloader, whose code I have been studying for inspiration. Also, I loved the https://github.com/dimitri/kids repo.

To me, an el-get distribution would be such a good and progressive improvement. I am not a a proficient elisp-coder, especially for el-get standard. Is there any way to create a "Discussion" section in this GitHub repository, like, for example, kons-9, so that proficient contributors from the past could be involved?

@dimitri
Copy link
Owner

dimitri commented Aug 18, 2022

I believe https://github.com/dimitri/el-get/discussions should be open for new discussions!

@lispstudent
Copy link
Contributor

Wow, very nice!

@elliottslaughter would you feel like bringing this ticket there and start a discussion? Who among the numerous contributors could help as a moderator, even just for this one? A proper knowledge of the code would be good for such role.

@elliottslaughter
Copy link
Author

Posted: #2870

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants