code

Emacs의 패키지 관리자에게 무엇을 기대합니까?

codestyles 2020. 10. 27. 08:16
반응형

Emacs의 패키지 관리자에게 무엇을 기대합니까?


수천 개의 Emacs Lisp 라이브러리가 존재하지만 GNU Emacs 버전 24.1까지는 (내부) 패키지 관리자가 없었습니다.

대부분의 사용자는 현재 Emacs Lisp 라이브러리를 찾고, 설치하고, 특히 최신 상태로 유지하는 것이 다소 불편하다는 데 동의 할 것입니다.

삶을 조금 더 쉽게 만들어주는 페이지

24.1 이전의 Emacs 버전 :

  • Emacs Lisp 목록 -문제 : 죽은 사람이 보입니다 (링크).
  • Emacswiki- 문제점 : 견과류 (악성 코드) 흔적이있을 수 있습니다.
  • Emacsmirror- 내가 작업하고있는 패키지 저장소. 문제 : 아직 기본적으로 지원하는 패키지 관리자가 없습니다.

일부 패키지 관리자

아직 아무도 시도하지 않은 것은 아닙니다. (이 질문을했을 때 이들 중 일부는 존재하지 않았습니다.)


업데이트-package.el은 버전 24.1부터 GNU Emacs에 포함되어 있습니다.


패키지는 Emacs 트렁크에 포함되었습니다. epkg는 아직 준비되지 않았으며 현재 사용할 수 없습니다. 적어도 install-elisp, plugin 및 use-package는 더 이상 적극적으로 유지 관리되지 않는 것 같습니다.

이 모든 패키지 관리자를 하위 모듈로 포함 하는 git 저장소만들었습니다 .

유용 할 수있는 일부 유틸리티

패키지 관리자는 이러한 유틸리티를 사용하거나 패키지 미러를 유지하는 데 사용할 수 있습니다.

당면한 주제에 대한 토론

질문 (마지막으로)

그래서-나는 당신이 Emacs의 패키지 관리자에서 중요하거나 중요하지 않은 / 보조적인 것 등으로 생각하는 것을 알고 싶습니다.

몇 가지 아이디어

  1. 많은 패키지 ( Emacsmirror 는 사용 가능한 가장 큰 패키지 모음을 제공하지만 아직 패키지 관리자에 대한 명시적인 지원은 없습니다).
  2. 테스트 된 패키지 만.
  3. 둘 이상의 패키지 아카이브 지원 (사용자가 여러 / 테스트 된 패키지 중에서 선택할 수 있음).
  4. 필수 기능만을 기준으로 계산 된 종속성입니다.
  5. 종속성은 특정 버전을 고려합니다.
  6. 업스트림으로 출시 된 버전 만 사용하십시오.
  7. 가능한 경우 버전 제어 시스템의 버전을 사용하십시오.
  8. 패키지가 분류됩니다.
  9. 패키지는 설치할뿐만 아니라 제거 및 업데이트 할 수 있습니다.
  10. 업스트림 버전 패키지의 포크 생성을 지원합니다.
  11. 이러한 포크 게시를 지원합니다.
  12. 포크 선택을 지원합니다.
  13. 설치 후 패키지가 활성화됩니다.
  14. 자동로드 파일을 생성합니다.
  15. Emacswiki와 통합 (wikirel.el 참조).
  16. 사용자는 패키지에 태그, 주석 등을 달고 해당 정보를 공유 할 수 있습니다.
  17. FSF 할당 / GPL / FOSS 소프트웨어 만 사용하거나 라이선스는 신경 쓰지 않습니다.
  18. 패키지 관리자는 Emacs와 통합되어야합니다.
  19. 저자와 쉽게 연락 할 수 있도록 지원합니다.
  20. 많은 메타 데이터.
  21. 특정 패키지를 설치하기 전에 대안을 제안하십시오.

이런 대답을 바라고 있어요

  • 더 많은 구현, 토론 등에 대한 포인터
  • 이상적인 패키지 관리자를 구성하는 기능 세트에 대한 긴 설명.
  • 특정 원하는 / 원하지 않는 기능에 대한 설명입니다. 위의 아이디어에 대해 자유롭게 설명하십시오.
  • 놀랍게도.

버전 제어에서 자동 게시

표준, 중앙 및 단일 Emacs 패키지 관리자 를보고 싶습니다 . 지금 당장은 ELPA에 돈을 걸 었지만 아직 갈 길이 멀다.

Emacs 패키지 관리자에게 도움이되는 가장 큰 것은 패키지 게시를 매우 간단하게 만드는 것입니다. 제 생각에는 GitHub 와 같은 중앙 호스팅 플랫폼 에서 git과 같은 버전 제어 시스템과 결합하여 이러한 일이 발생하는 것을보고 싶습니다. 이는 작성자가 패키지를 쉽게 게시하고 다른 사람들이 쉽게 할 수 있도록합니다. 다시 기여하십시오.

GitHub (예전)를 사용하여 RubyGems를 쉽게 게시하는 방법과 유사하게 Emacs 패키지 관리자에서 유사한 내용을보고 싶습니다. 예를 들어 저장소에 "vX.YZ"태그를 지정하고 모든 사용자가 자동으로 elisp 기능을 사용할 수 있도록합니다.

GitHub와 같은 인기있는 백엔드를 사용하는 추가 이점은 성공을 촉진하는 데 도움이되는 많은 노출을 즉시 얻을 수 있다는 것입니다.


나는 여전히 Emacs를 배우고 있기 때문에 패키지 관리자를 살펴볼 기회가 없었지만, 훌륭한 기능은 사용자가 패키지를 사용하려고하지만 시스템에없는 경우 사용할 수 있음을 사용자에게 알리는 것입니다. 예를 들어 서버에서 PHP 파일을 한 번 편집하고 싶었는데

M-x php-mode

Emacs는 모두

M-x php-mode [no match]

그랬어 야 할 때

php-mode available from ftp.gnu.org. install? (y/n)

그런 다음 나를 위해 php-mode를 설치하고로드했을 것입니다. 그게 바로 내 하루를 만들었을 것입니다.


내가 가장 기대하는 것은 유용한 모든 것이 그 위에 있고 잘 작동 한다는 입니다. 이를 위해서는 모든 것을 패키징하고 유용한 패키지의 모든 작성자에게 이메일을 보내는 등 모든 작업을 적극적으로 수행해야합니다.

예를 들어, 데비안 (및 그 파생물 : 우분투 등)이 좋은 이유는 저장소 외부에 무언가를 설치하지 않고도 시스템을 행복하게 사용할 수 있고 그 안에있는 모든 것이 철저하게 테스트되기 때문입니다. 패키지 관리자의 실제 기능은 중요하지만 관리되는 패키지 자체의 보조 기능입니다.


손쉬운 구성 동기화 : 많은 사람들처럼 저도 여러 컴퓨터와 서버에서 Emacs를 사용합니다. 일부는 제 소유이고 일부는 사용하지 않습니다. 패키지 관리자에 내가 한 컴퓨터에서 다른 컴퓨터로 전송할 수있는 일종의 파일이 있다면 놀라 울 것입니다. 그런 다음 후자의 컴퓨터에서 패키지 관리자는 내 Emacs를 내가 좋아하는 상태 (설치된 모든 패키지와 설정 설정)로 만듭니다. 사이트 전체 (루트 권한이있는 경우) 또는 단일 사용자로 쉽게 설치할 수있는 기능과 결합하여 모든 Emacsen을 어디서나 동기화 할 수 있습니다.


I'm nearly positive that the best solution involves submitting more packages to ELPA and adding multi-source support to package.el. The Emacs maintainers have said that they would consider including package.el in version 24 as long as it pointed to an FSF repository by default.

Of course, submission also needs to be an automated process too; the current method of mailing the ELPA maintainer only works on a small scale.


No matter how this is done, the most important thing in my opinion is that it should be trivial to submit packages to the repository. At the same time, we do not want those packages to be instantly available, to guard against malicious code(and due to licensing issues). Unless there is a "trust" system in place, based on crypto signatures.

Also useful:

  • "metapackages", to install several packages at once.
  • In the same way, we should be able to install a set of elisp files, for maintainability
  • "Broken" packages should not be allowed to disrupt Emacs startup. This is easy and I have it implemented in my own .emacs
  • Ability to install files other than scripts. This is often overlooked, but very useful. You'd be able to, for instance, ship images, for icons, toolbars, etc.
  • Versioning:package X requires package Y > 1.0
  • Testing: perform basic sanity checks, testing for conflicts (keybindings, function redefinitions, functions that are expected to be present but aren't, etc).
  • BUG TRACKING: I can't stress the importance of this enough. Having a centralized place to report package bugs (and being able to track them) is extremely important to assure the quality of the packages.

Some sort of compressed archive seems to be best to do some of the above.


So far, a much improved ELPA seems the way to go.


I once spent some time writing a small package manager for Emacs.

http://gmarceau.qc.ca/plugin.el

I wrote:

Plugin is my attempt at creating a package manager for Emacs. Plugin will automatically downloads Emacs extensions, unpacks them in a directory, adds that directory to the load-path, generates auto-load annotations, and modify your dot-emacs file. The auto-load annotations are a little-known feature of Emacs. Once they are generated, Emacs extensions load quickly and incrementally, which is really nice if you have as many extensions installed as I do.

You will need two library files to get it to run, loop-constructs.el and record.el


I think the hackers for the iPhone got quite close to what I want, as does Ubuntu's "apt".

I like to be able to:

  • add
  • remove (package only)
  • remove user settings
  • view documentation
  • upgrade ( after reading the change log)
  • add new archive ( aka add repository )
  • see dependencies
  • see version
  • search for name, keyword
  • browse by (date added, date modified, name)
  • save all installed packages & settings
  • load set of packages & settings

I would like a main set of things that all work nicely and are the recommended way of doing whatever. Then a global set where everything working gets in. Then the ability for anyone to host their own archive.

It would be nice if this was all tied into git/svn/whatever so that you could install old versions. Make your own patches by forking off etc etc etc....


Besides the mentioned above, i expect something like debian, and other repositories - set of the stable, experemental, untested packages. Ability to add my own repositories - i use lot of the packages directly from VCS, so it could be useful to create my own packages


I think that the package manager should take a lot of inspiration from Rubygems. I also think that it should have a site like Gemcutter.

A central repository could also be nice (like Emacsmirror). This however may not be necessary if a site like Gemcutter exists that collects all packages.

I think these things are important for this to work.

  • Central location of some kind that collects all packages
  • Easy to add packages
  • Easy to maintain packages
  • Easy to contribute to other packages
  • Easy to install, uninstall and update packages
  • Possibility to add package dependencies
  • Common structure for all packages

So a package manager like Rubygems with a site like Gemcutter and a central repository like Emacsmirror (preferably on Github because of it's social coding) would do Emacs really good.

All in all I think that much inspiration should be taken from Rails and how Rails handles Gems.


I don't know how fresh this question is...
but the model I would like to see is CPAN. I also don't know Rubygems but it sounds similar to CPAN.

CPAN is a perl archive + library management system. When I need to write a perl program that requires... FTP or SOAP or JSON or XML or ZIP, or...etc, I can run the CPAN package manager, select the requisite package for download, view and verify the dependencies, then install everything. CPAN is mirrored .."everywhere".

CPAN works wonderfully for my purposes, and something similar for emacs would be nice to have. It also supports building C/C++ code on demand.

That's what I would like to see in emacs.

Some further comment on requirements.

  • explicit download of packages. No auto install. No invisible downloads. I want to ask for new libraries or new function.
  • I should be able to list the name/version/timestamp of installed packages.
  • If my friend gives me his list, I should be able to diff his emacs state against mine.
  • check-for-updates function. What updates are available? What do they fix?
  • depedency checking, verification, and download. If I install csharp-mode and it requires v5.0.28 of cc-mode, then it should confirm with me, that I must also download cc-mode.
  • there should be some sort of community ranking of these packages, like ranking torrents on isohunt. I want to see if a package has 3 upvotes or 3000.
  • "transactional" behavior. If an install goes boom, it must unwind to a last-known-good state.
  • failsafes. If I've put custom mods in linum.el, it should refuse to install a new version over my changes, unless I explicitly allow it. It should warn me before even starting. Do this with checksums/md5's over the existing install.
  • have the option of running some packages from compressed archives, like zip files. So I never have any doubt that I have not updated any of the embbedded elisp.
  • ability to use mirrored hosts for package distribution.
  • all this function should be accessible through M-x library-manageemnt or something.

Finally, it would be nice to have a way to segregate or organize libraries of functions. Hierarchical namespaces. Emacs' flat namespace is very dated. This is sort of independent but complementary to the core function of package management. I'm not a lisp guru so I don't know how hard this would be; maybe there is already a way to do it.


Package managers don't offer anything I value w.r.t. single-file elisp packages with simple dependencies: adding and deleting from site-lisp has never caused problems. It's packages that depend on external programs (e.g., ispell), multi-file packages (e.g., auctex, org-mode) that can be tricky. Can't think of any single-file elisp package with nontrivial dependencies, offhand.

For these, short of a package manager, I'd like emacs' elisp-packages to acquire test suites which can be run en masse, and which provide useful information in the event of dependency failures.

참고URL : https://stackoverflow.com/questions/454259/what-do-you-expect-from-a-package-manager-for-emacs

반응형