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

Need more explicit installation information in the README.md #44

Open
igolotin opened this issue Dec 17, 2021 · 0 comments
Open

Need more explicit installation information in the README.md #44

igolotin opened this issue Dec 17, 2021 · 0 comments

Comments

@igolotin
Copy link

Context

I had read the README and left the reading puzzled. The big question was which of the two origami versions are actually distributed through MELPA. And how should I install the right version and how to avoid accidently reinstalling the wrong version.

README had not covered the topic so I dived into the Announcement discussion. It was educative in a way. I have never imagined how much hassle is maintaining emacs packages always taking it for granted. To summarize:

  1. Original maintainer is totally satisfied with his project being frozen. It has all the functionality he needs
  2. Community introduce some changes, extended syntax support and so on. Jen-Chieh Shen take initiative and create fork
  3. MELPA support keep themselves aloof from choosing. The early bird gets the worm. Simple and unbiased rule for resolving any conflict
  4. And there is a conflict indeed. All the packages share the single namespace. So there is a rule: no package should impose name conflict with other packages. Newer packages should not take old packages names. Forked and renamed project could not be put in the MELPA repository simultaneously with the original.
  5. So forked package should have of all its functions and variables names refactored to avoid conflict. The package maintainer is obliged with much work for nothing. Moreover he could not pick up PR and patches from the original project after the refactoring.
  6. And renaming is disastrous for integration with other packages that relies on original names. Existing user configuration would become nonfunctional too.
  7. Submitting to terms the new maintainers decides to leave things as is and abandons registering reworked project in the MELPA repository. He is satisfied with the decision and keep using his project to its full power.
  8. MELPA support is satisfied too with the outcome since it has to do nothing.
  9. The original maintainer is satisfied of course as MELPA had kept his priority to the package.
  10. And the real users are on the looser side. They should rack theirs brains over non-trivial installation process.
  11. Conflict could be solved on the package manager level introducing blockers, variants, virtual packages. System package manager regularly face similar troubles and found solution for namespace conflicts long ago. But emacs is a text editor and have little focus on secondary tasks like package management improvement. So we should work with existent capabilities.

The problem

The README doesn't touch ambiguous state of the origami. It says nothing about MELPA and CELPA. User should undertake a research to discover the current state. And then perform another research towards configuring emacs lisp package archive.

Suggestion

And extra information in the README file addressing the original origami and the fork distribution.

  1. State explicitly that original project is still delivered through MELPA despite being frozen
  2. Mention CELPA switched to the forked project. Provide info and links about CELPA distribution, and ELPA configuration to use CELPA instead of MELPA
  3. Give information about using MELPA and CELPA simultaneously. So that all projects are normally installed from MELPA but explicitly marked installed from CELPA. Could be your own experience or link to third-party manual.
  4. Describe how to install from git, step-by-step. Or give an appropriate link for a detailed description. I always have used package installation and never build a package myself. But package maintainer should have experience on building packages manually. Since a package should be tested locally before uploading it in the package repository. I'm not sure, but manually installing a package could be easier than configuring two package repositories for the sake of single package.

Me personal experience

I googled about manual installation and found quelpa which should help with installing package from a git source, but never bothered about testing it. I had choose to invoke CELPA instead.

So that is my configuration:

(setq package-archives
      '(("gnu"   . "https://elpa.gnu.org/packages/")
	("melpa" . "https://melpa.org/packages/")
	("celpa" . "https://celpa.conao3.com/"))
      package-archive-priorities
      '(("gnu"   . 40)
	("melpa" . 20)
	("celpa" . 0))
      package-pinned-packages
      '((origami . "celpa"))
)
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

1 participant