• (eepitch-shell) cd foo tar xvf testpackage-0-0.tar • (add-to-list 'load-path "~/foo/testpackage-0.0") • (load "testpackage") • (apropos "testpackage") => testpackage-func is an interactive Lisp function in ‘testpackage.el’.
Ah, yeah, I thought a little bit more and you weren't actually saying I-want-to-load-this-file. I guess the concept of a package in emacs lisp does not resemble common lisp at all. I.e. a symbol doesn't have a package like a lisp symbol does. Packaging refers to packaging e.g. a mode for distribution, right? At which point I think we would refer to e.g. melpa github.com/melpa/melpa?tab=rea… about what melpa wants you to do. That's my 25 cents anyway. @sacha
i think -pkg files are possibly outdated or else rarely used (i have never used mastodon.el's, it is just there, possibly stale code). your testpackage doesn't seem to have enough juice in it to be a package, normally it'd have a provide statement at end, and in that file, there is possibly not enough in your file headers. try `auto-insert` to insert a file header will some details, or look at some existing Emacs packages (their main files). eg codeberg.org/martianh/mastodon…. or perhaps read up on the docs about writing a package, regardless of multi files or not? (these are my random ideas after looking at your files.) (+ re your first comment, docs may well be lies. i learned about multi files pkgs (after accidentally inheriting one) only by looking at existing ones that i actually use and asking folks when stuck.)
If we look at Xahlee's site here: xahlee.info/emacs/emacs/elisp_… he notes that "The terms “Package” and “Library” do not have technical meaning in elisp.
The term “module” is not used by emacs."
} really, we are concerned with writing modes for emacs. Packaging them for distribution means meeting the package-source's requirements for the mode to be built and then distributed from a git, e.g.. That is my other 25 cents ;p.
This is different to #commonLisp in which I might CL-USER> (uiop:define-package foo) #<"FOO" package> CL-USER> (in-package foo) #<"FOO" package> FOO> (defvar bar) BAR FOO> (export 'bar) T
} this is not an emacs idiom. Similarly, common lisp does not have a notion of interaction major and minor modes like emacs does. I guess package in emacs means something similar to system in the de facto asdf sense in common lisp. In my opinion this collision is confusing.
it feels like you're manually creating a .tar like what would be in an ELPA, but you can submit things to NonGNU ELPA or MELPA as a recipe, which can include your .texi manual if you want. github.com/melpa/melpa/blob/ma…emacsredux.com/blog/2021/08/11… . Before inclusion in one of those repos, people can also install it manually or with use-package :vc or package-vc-install: gnu.org/software/emacs/manual/…
Recently I wrote an article about NonGNU ELPA and I promised to check for myself how easy it is to submit a new package there. I made good on my promise and in this article I’ll briefly describe the process.
@Sacha Chua @screwlisp Yeah, that's essentially what I'm trying to do. My eventual goal is to create my own semi-private ELPA archive, mostly because I don't want to bother people with having to review my probably terrible novice code before including it in their archives. 🙃
None of this code is really ready for public consumption yet. It's more of a learning exercise.
I picked a trivial multifile package example, seq: Tree: gitweb.git.savannah.gnu.org/gi… A package of three files, seq.el, seq-24.el and seq-25.el, and if you are in emacs 25 or later, seq.el requires seq-25 or seq-24 otherwise. Presumably your multi-file elisp project should meaningfully resemble seq e.g. with the conventional package headers.
Yes, you don't write that stuff. []. You just write your major/minor modes as normal, and your headers provide metadata that is used by package sources to generate the package tars. @sacha
as we can see in > (directory "~/.emacs.d/elpa/seq-2.24/*.*") (#P"~/.emacs.d/elpa/seq-2.24/seq.elc" #P"~/.emacs.d/elpa/seq-2.24/seq-25.elc" #P"~/.emacs.d/elpa/seq-2.24/seq-24.elc" #P"~/.emacs.d/elpa/seq-2.24/seq-autoloads.el" #P"~/.emacs.d/elpa/seq-2.24/seq-25.el" #P"~/.emacs.d/elpa/seq-2.24/seq-pkg.el" #P"~/.emacs.d/elpa/seq-2.24/seq.el" #P"~/.emacs.d/elpa/seq-2.24/seq-24.el") if you will forgive some of the-other-lisp ;p @sacha
@screwlisp @Sacha Chua What I'm curious about is how it made the determination that seq.el was the main file. This is fairly obvious with my human intuition. Was it just because all the other .el files started with seq-, or was it doing something more fancy by looking at the contents of the files and seeing what requited what?
Edit: Ah, I bet it has to do with the fact that only seq.el had ;; Package: and ;; Version: lines, which explicitly set the package name (and version).
I thought maybe it needed to be in some GNU variant of the tar format for Emacs to be able to read it, but when I just open the tar file directly in Emacs I get a directory listing and can read all the files, so that's not it.
You could try package-build-create-recipe It will need to be filled in, but if your headers are correct, with author, packages-required, version, etc.
Edit the recipe for your git. You'll be in recipe mode. Saving it puts it in .../elpa/recipes/ Building it with C-c C-c will make a package and install it in your elpa..
That might teach you what you need.
It will automatically pick up .el and .texi files. Not eld, but if you have some odd file, you can add the pattern to the recipe. I have an eld which is not in the list of automatic files.
Jonathan Lamothe
in reply to Jonathan Lamothe • •cloud.jlamothe.net/index.php/s…
#AskFedi
reshared this
screwlisp and vejeta ☑️ reshared this.
Jonathan Lamothe
in reply to Jonathan Lamothe • •FWIW it seems to be complaining that the package description is
nil. Two things about this:define-packagelists this argument as optional.Jonathan Lamothe
in reply to Jonathan Lamothe • •screwlisp
in reply to Jonathan Lamothe • • •• (eepitch-shell)
cd foo
tar xvf testpackage-0-0.tar
• (add-to-list 'load-path "~/foo/testpackage-0.0")
• (load "testpackage")
• (apropos "testpackage")
=>
testpackage-func is an interactive Lisp function in ‘testpackage.el’.
(testpackage-func)
A test function
[back]works on my machine
@sacha
Jonathan Lamothe
in reply to screwlisp • •@screwlisp @Sacha Chua When I try to install it with
M-x package-install-fileit gives me:Wrong type argument: stringp, nilWhen I use the debugger it seems to be caused by it thinking the package description is
nil? I'll try to dig deeper.screwlisp
in reply to Jonathan Lamothe • • •@sacha
GitHub - melpa/melpa: Recipes and build machinery for the biggest Emacs package repo
GitHubscrewlisp
in reply to screwlisp • • •mousebot
in reply to screwlisp • • •mastodon.el/lisp/mastodon.el at main
Codeberg.orgscrewlisp reshared this.
Jonathan Lamothe
in reply to screwlisp • •@screwlisp @Sacha Chua Yeah, I can build simple packages, but the description for how to build a multi-file package seems not to work.
Most packages are distributed in the simple format, but if you want to include a manual for instance, you need a multi-file package.
screwlisp
in reply to Jonathan Lamothe • • •If we look at Xahlee's site here: xahlee.info/emacs/emacs/elisp_… he notes that
"The terms “Package” and “Library” do not have technical meaning in elisp.
The term “module” is not used by emacs."
} really, we are concerned with writing modes for emacs. Packaging them for distribution means meeting the package-source's requirements for the mode to be built and then distributed from a git, e.g.. That is my other 25 cents ;p.
Elisp: load, load-file, autoload
xahlee.infoscrewlisp
in reply to screwlisp • • •This is different to #commonLisp in which I might
CL-USER> (uiop:define-package foo)
#<"FOO" package>
CL-USER> (in-package foo)
#<"FOO" package>
FOO> (defvar bar)
BAR
FOO> (export 'bar)
T
} this is not an emacs idiom. Similarly, common lisp does not have a notion of interaction major and minor modes like emacs does. I guess package in emacs means something similar to system in the de facto asdf sense in common lisp. In my opinion this collision is confusing.
Jonathan Lamothe
in reply to screwlisp • •gnu.org/software/emacs/manual/…
Sacha Chua
in reply to Jonathan Lamothe • • •Submitting a Package to NonGNU ELPA
Bozhidar Batsov (Emacs Redux)Jonathan Lamothe
in reply to Sacha Chua • •@Sacha Chua @screwlisp Yeah, that's essentially what I'm trying to do. My eventual goal is to create my own semi-private ELPA archive, mostly because I don't want to bother people with having to review my probably terrible novice code before including it in their archives. 🙃
None of this code is really ready for public consumption yet. It's more of a learning exercise.
screwlisp
in reply to Jonathan Lamothe • • •I picked a trivial multifile package example, seq:
Tree: gitweb.git.savannah.gnu.org/gi…
A package of three files, seq.el, seq-24.el and seq-25.el, and if you are in emacs 25 or later, seq.el requires seq-25 or seq-24 otherwise. Presumably your multi-file elisp project should meaningfully resemble seq e.g. with the conventional package headers.
Then, I think you are basically looking for quelpa: github.com/quelpa/quelpa
@sacha
GitHub - quelpa/quelpa: Build and install your Emacs Lisp packages on-the-fly directly from source
GitHubJonathan Lamothe
in reply to screwlisp • •@screwlisp @Sacha Chua What's interesting is that this package seems to be lacking a
seq-pkg.elfile. 🤔Edit: Wait, it's in
.gitignore?Is it being auto generated somehow?
screwlisp
in reply to Jonathan Lamothe • • •@sacha
screwlisp
in reply to screwlisp • • •> (directory "~/.emacs.d/elpa/seq-2.24/*.*")
(#P"~/.emacs.d/elpa/seq-2.24/seq.elc"
#P"~/.emacs.d/elpa/seq-2.24/seq-25.elc"
#P"~/.emacs.d/elpa/seq-2.24/seq-24.elc"
#P"~/.emacs.d/elpa/seq-2.24/seq-autoloads.el"
#P"~/.emacs.d/elpa/seq-2.24/seq-25.el"
#P"~/.emacs.d/elpa/seq-2.24/seq-pkg.el"
#P"~/.emacs.d/elpa/seq-2.24/seq.el"
#P"~/.emacs.d/elpa/seq-2.24/seq-24.el")
if you will forgive some of the-other-lisp ;p
@sacha
Jonathan Lamothe
in reply to screwlisp • •@screwlisp @Sacha Chua What I'm curious about is how it made the determination that
seq.elwas the main file. This is fairly obvious with my human intuition. Was it just because all the other.elfiles started withseq-, or was it doing something more fancy by looking at the contents of the files and seeing what requited what?Edit: Ah, I bet it has to do with the fact that only
seq.elhad;; Package:and;; Version:lines, which explicitly set the package name (and version).Jonathan Lamothe
in reply to Jonathan Lamothe • •Sacha Chua
in reply to Jonathan Lamothe • • •Jonathan Lamothe
in reply to Jonathan Lamothe • •Ah. I assume that this would live somewhere near the top of my
testpackage.elfile?Edit: Looking at other examples, it tends to be found at the bottom.
Zenie
in reply to Jonathan Lamothe • • •You could try package-build-create-recipe
It will need to be filled in, but if your headers are correct, with author, packages-required, version, etc.
Edit the recipe for your git. You'll be in recipe mode.
Saving it puts it in .../elpa/recipes/
Building it with C-c C-c will make a package and install it in your elpa..
That might teach you what you need.
It will automatically pick up .el and .texi files.
Not eld, but if you have some odd file, you can add the pattern to the recipe. I have an eld which is not in the list of automatic files.
See the contributing doc at GitHub Melpa.
Jonathan Lamothe likes this.
Zenie
in reply to Zenie • • •You want something like this?
oitofelix.github.io/elpa/
See the link to elpa-deploy halfway down.
oitofelix - ELPA
oitofelix.github.io