Prepare a ELPA/Marmalade package of Pymacs

[gleber]

This would make installing Pymacs much easier and will, for sure, increase number of users.

Best,
Gleb Peregud

[pinard]

Hello, Gleb.

"Increasing number of users" is not much of a goal for me. However, the users I have, I prefer them happy! :-)

Now, I do not find Pymacs installation to be especially difficult, but I may be biased, so I'm surely willing to listen. On the other hand, I do not want to be pulled into everything that moves around.

Would Marmelade interface to GitHub to fetch what it needs, or would I have the burden of uploading to Marmelade on a regular basis? If yes, could this be fully automated? Would Marmelade be any helpful for the Python part of Pymacs? Are users expected to install Marmelade or do special things before being able to take "advantage" of it? And if yes, is the total burden bigger or smaller than the current installation procedure? Would my users stay free to not use Marmelade?

If you honestly think the effort is meant to improve Pymacs rather than to evangelize Marmelade, by all means tell me more. Would you be ready to contribute whatever it needs, or at least, give a serious hand at getting me started?

François

I do not much know Marmelade, and I do not much use ELPA either. However, ELPA has been created by Tom Tromey, who is an old friend, so I have quite a favorable prejudice. Proof of me being human! :-)

[gleber]

Hello François

Few glossary explanations follows. Sorry if something is too obvious, but it seems you need an updated on this topic :)

ELPA and Marmalade are just servers which are working as a repositories for packages. Both works according to package.el standards, which has been integrated into Emacs 24. Afaik ELPA is a default repo for package.el, but Marmalade is more modern and much easier to use for package maintainer. Packages are basically either a single .el file or a tar file with multiple .el files in it (but it can contain any other type of files too). package.el supports fetching list of packages in all attached repositories, it supports two-keystrokes installation of packages, it supports updating packages, it supports deleting packages. Additionally package.el, by default, loads appropriate .el files from package on emacs start, which allows for zero-configuration of package features (e.g. adding keybindings, etc.).

Answers are inlined:

"Increasing number of users" is not much of a goal for me. However, the users I have, I prefer them happy! :-)

My use case is to automate installation of ropemacs in my Emacs-prelude setup. It would make me happy :)

Now, I do not find Pymacs installation to be especially difficult, but I may be biased, so
I'm surely willing to listen. On the other hand, I do not want to be pulled into
everything that moves around.

If it is done according to package.el stuff and put to ELPA or Marmalade, installation ca be done just with "M-x package-install RET pymacs RET" directly from Emacs. There are some technical details which are yet not fully known to me, but I'll figure it out.

Would Marmelade interface to GitHub to fetch what it needs,
or would I have the burden of uploading to Marmelade on a regular basis? If yes, could this be fully automated?
Unfortunately not. But Marmalade repository provides a very simple API, which can be integrated into your Makefile, which would make things super simple.

Would Marmelade be any helpful for the Python part of Pymacs?

AFAIK it would be enough to set PYTHONPATH env inside Emacs to place where pymacs.py lives, so when pymacs.el tries to start pymacs.py it just works. It needs testing.

Are users expected to install Marmelade or do
special things before being able to take "advantage" of it?

At the moment - yes. When Emacs 24 becomes standard - almost nothing. If pymacs package is in ELPA, user would have to do nothing. If it is added to Marmalade, user would have to add Marmalade's repository URL to it's configuration.

And if yes, is the total burden bigger or smaller than the current installation
procedure?
Yes. Just one command directly from Emacs.

Would my users stay free to not use Marmelade?
Yes. Again, Marmalade is just a repository of packages. User is actually using package.el, which would be standard starting from Emacs 24.

If you honestly think the effort is meant to improve Pymacs rather
than to evangelize Marmelade, by all means tell me more. Would
you be ready to contribute whatever it needs, or at least, give a
serious hand at getting me started?

Yes, I would like to help. Although not today :)

François

I do not much know Marmelade, and I do not much use ELPA
either. However, ELPA has been created by Tom Tromey, who
is an old friend, so I have quite a favorable prejudice.
Proof of me being human! :-)
It would be helpful ;) You could have easier access to upload things to ELPA, since uploading packages to ELPA repository is manual - i.e. you send an email to Tom and he adds it there. It would be nice if Tom switches to Marmalade server, which is open source software and allow users to upload their package without repository owner manual intervention.

I'll follow up this issue later this week to provide more information, if you need it :)

Best regards,
Gleb

[pinard]

Gleb Peregud writes:

ELPA and Marmalade are just servers which are working as a
repositories for packages.

There is an ELPA from GNU, for Emacs 24 and later, and ELPA from Tom
Tromey. I do not really know if they differ or are the same thing. If
they differ, the former has been inspired by the latter, but I would
also presume that the former is more restrictive than the latter.
Marmalade is likely an ELPA with less politics in it, I still miss the
part of history or justification for Marmalade despite Tom's ELPA.

There is also this el-get for the fetching mechanics which is yet
another ELPA extension, and I got that there are a few others too. I
tried el-get a few weeks ago. Despite easily enthusiastic, I try to
stay careful. While this tool seemed to work nicely at first, I met a
few problems using it, one being that some packages were lagging too
much. There might have been other issues, which I forgot since. So, I
decided it safer or saner for me, and more flexible all considered,
doing installations in more traditional ways. If the tool was not good
enough for me, it might not be good enough for my users as well.

Both works according to package.el standards, which has been
integrated into Emacs 24.

Which is not yet widely current in all Linux distributions.

Afaik ELPA is a default repo for package.el,

GNU's ELPA, not Tom Tromey's one. (Presuming they differ)

but Marmalade is more modern and much easier to use for package
maintainer.

All such packages claim about exactly the same thing about one another.
Difficult to decide which is right, all the others being wrong! :-)

automate installation of ropemacs in my Emacs-prelude setup [...]
would make me happy :) [...] I'll follow up this issue later this
week to provide more information, if you need it :)

You'll have my collaboration, as long as Pymacs users are not impacted,
and that it does not much increase my own maintenance burden.

Would Marmalade be any helpful for the Python part of Pymacs?
AFAIK it would be enough to set PYTHONPATH env inside Emacs to place
where pymacs.py lives, so when pymacs.el tries to start pymacs.py it
just works. It needs testing.

And a bit of thought too. PYTHONPATH is primarily meant for the user,
and should be left alone as far as possible.

Are users expected to install Marmalade or do special things before
being able to take "advantage" of it?
At the moment - yes. When Emacs 24 becomes standard - almost nothing.

So, maybe the effort is a bit premature. We should follow, not precede.

And if yes, is the total burden bigger or smaller than the current installation
procedure?
Yes. Just one command directly from Emacs.

I got that prior to Emacs 24, users also have to fetch and install
package.el, and configure it. Then it may be just one command.
Overall, it is far from being merely one command -- we have to stay
honest here.

Would my users stay free to not use Marmalade?
Yes.

This makes the whole thing more bearable! :-)

You could have easier access to upload things to ELPA, since uploading
packages to ELPA repository is manual - i.e. you send an email to Tom
and he adds it there.

Through Tom, even for the GNU ELPA? If it is to be manual all the time,
it is a serious drawback.

It would be nice if Tom switches to Marmalade server, which is open
source software and allow users to upload their package without
repository owner manual intervention.

Did you discuss the matter with him? What was the outcome? What does
he think?

The idea of some automatic upload (provided there are enough security
measures) is attractive, indeed.

François

[pinard]

Of interest to this thread: "Package Management in Emacs: The Good, the Bad and the Ugly - (think)" http://batsov.com/articles/2012/02/19/package-management-in-emacs-the-good-the-bad-and-the-ugly/

[gleber]

Looks like my information on packages was not accurate and I needed an updated on this topic as well :)

Looks like Tom's ELPA is not the same as GNU's ELPA. GNU ELPA is so user un-friendly. Their web page provides NO information about how to contribute. So I have no idea how to contribute there.

I haven't yet pinged Tom about idea of the switch to Marmalade's software. There is also MELPA [1], but I dislike it's development package focus. Emacs is my primary tool, hence I want it to work well all the time.

At the moment I find Marmalade to be the best place, although it's maintainer seems to be ignoring the project at the moment. I hope it will change.

I think that a safe conclusion of Bozhidar's article is that package.el-based packaging for Emacs is here to stay. So in general, since it won't hinder user experience of current users of Pymacs and may make it's installation easier for others, creating a ELPA/MELPA/Marmalade package would only benefit at least someone :)

I'll prepare a pull request which adds a make command which creates a package this or next week.

Cheers,
Gleb

1: http://melpa.milkbox.net/

[pinard]

Hi, Gleb. OK, I finally found some time to ponder the avenues, and I've decided that your way is the most fruitful one. Many problems are still unsolved, but let's take a first step. Let me thank you for your collaboration and patience! More news shortly about this. François

[pinard]

OK. I think that Pymacs (at least pymacs.el) has the necessary shape for being uploadable to some ELPA. What is missing is the automated uploading to some some ELPA. Marmelade has an API for doing so, I do not know if it works well and did not try it. In fact, I guess I could not do it, as Pymacs 0.24 has already been uploaded by someone else, and presumably, one cannot obliterate an uploading made by another. It would represent the hell of a security problem otherwise (if not already!). The other half of the problem is the Python side, for which I might consider Python installers.

Thanks for the incentive and collaboration. Do not hesitate to write again if anything else. François

[dicato]

For awareness, the emacs side of installation is handled if you use emacs-for-python. http://gabrielelanaro.github.com/emacs-for-python/ It's cheating, but it works. I wrote a homebrew formula to install pymacs. Of course that will only help OSX users. I feel that the python side of pymacs should be handled by pypi. I suspect the maintainers of homebrew won't allow the pymacs formula in the official repo, but we shall see.

Just my thoughts, sorry for jumping into the convo!

[pinard]

Locker537
reply@reply.github.com
writes:

http://gabrielelanaro.github.com/emacs-for-python/

By the way, thanks for this link, I'll take a more serious look, for my
own personal benefit :-).

I feel that the python side of pymacs should be handled by pypi.

OK, I'll peek at what it would mean to use it.

Just my thoughts, sorry for jumping into the convo!

By all means, don't be sorry. You're welcome!

François

P.S. What is your name? GitHub did not tell me :-)

[dicato]

pypi really just needs a setup.py file, which is seems you already have :-)
Since the setup.py script is a plain old python script, you could have it place the proper .el files in the correct location by assuming defaults or prompting the user.

My name is Steve.

[pinard]

Locker537
reply@reply.github.com
rites:

pypi really just needs a setup.py file, which is seems you already have :-)

Hi, Steve! Yes, thanks, uploading worked easily indeed, yet freezing
from my current configuration, which is Python2 and not MacOS X.
This might be a problem for you. Repeating from ppppconfig.py:

DEFADVICE_OK is 't' when it is safe to use defadvice. It has been reported

that, at least under Aquamacs (an MacOS X native port of Emacs), one gets

"Lisp nesting exceeds `max-lisp-eval-depth'" messages while requesting

functions documentation (we do not know why). Set this variable to 'nil'

as a way to avoid the problem.

However, further installation from PyPI does not seem to work well here,
I'll try a bit to understand why.

Since the setup.py script is a plain old python script, you could have
it place the proper .el files in the correct location by assuming
defaults or prompting the user.

It's quite amusing. With Python eyes, people see the installation of
the Emacs Lisp file as trivial. With Emacs Lisp eyes, people see the
installation of the Python file as trivial. I guess neither are.

François

[dicato]

Nothing is ever really trivial. ;-)