Why does emacs-nox require python39

R

ralphbsz

I'm just completely reinstalling my server at home, going from 32 bits to 64 bits, using release 13.2.

Found an interesting oddity: Installing emacs-nox as a package (I'm in the habit of not buildings things from ports unless absolutely needed) pulls in the package python39, which is Python version 3.9. But since I'm freshly installing, I would like to start with the most up-to-date version, which is Python 3.11. Which is perfectly possible, but then I'll have two python versions on my machine, which is one too many. Is there a reason that emacs needs the specific python39, and wouldn't be satisfied with the more generic python3 port (which auto-points to a recent version)?

If nobody knows a good reason, I'll contact the maintainer for emacs-nox, and see whether this is an oversight or a bug.
 
Python 3.9 might still be default python version for the systems creating the packages; it's actually not emacs that depends on python but a bunch of other packages that it pulls in. I've attached a dependency tree that hopefully makes this more transparent.
 

Attachments

Thank you for that full dependency tree! Very interesting.

So the real cause is that emacs depends on a lot of things (3300 of them, which makes sense and is fine), and 280 of those then depend on python39.

My sad conclusion is: I will probably have multiple python3 versions installed on my new system, with most of them unused (only dragged in because of dependencies), and one that I manually make my production version (right now, that will be 3.11). I don't think this will create serious problems; it means when doing updates and installs I have to be a little extra careful. And disk space is cheap.
 
From /usr/ports/Mk/bsd.default-versions.mk as of 2023Q4:
Code: 
# Possible values: 3.8, 3.9, 3.10, 3.11
PYTHON_DEFAULT?=        3.9

When locally building ports, you can easily change this in make.conf, when downloading packages you'll have to live with multiple versions.
 
I see ... that's the reason all these packages are using version 3.9. One way for me to deal with it is to say: if I want to use packages (and not build from ports), then I should keep my Python package also at the default version. That's probably not a big restriction, as I don't think I have software that requires newer versions.

I understand why package maintainers (of whom there are too few, and they are overworked) are unwilling to use the generic "use any Python 3" meta-package: If this causes any problems, they have extra work to deal with it.
 
I also use packages, they are a good "service", but I am fed up with unnecessary dependencies everywhere.

For emacs, I build it from the emacs distribution, do not even use ports, only so I managed to get a usable,
light weight emacs.
 
The "issue" is that packages or more correctly default configurations need to have "one size fits all" approach at least with current functionality of ports tree. If it's a leaf port with no dependencies you can have flavours but that isn't the case when you have lots of consumers of a port.
 
I've only just started using editors/emacs on an everyday basis, and am annoyed with myself for nor progressing with it years earlier. Now I'm wondering what I am missing out on by not using emacs-nox. Doesn't emacs -nw give you the same thing?
 
balanga said:
Now I'm wondering what I am missing out on by not using emacs-nox. Doesn't emacs -nw give you the same thing?
Click to expand...
The X version of emacs is somewhat different from the terminal (command-line) version in its interface. If you are just learning emacs, try both. Personally, I mostly use the command-line version, because I'm often working remotely on machines that have no X installed, so I don't want to learn to rely on X features that won't be available. On the other hand, if you only work on your own desktop/laptop machine, you can pick the one you prefer.

Biggest advantage (for me) of the X version: If you're displaying many files within an emacs window, you can change the size of the "windows" by grabbing with the mouse. Biggest disadvantage (for me): It wastes screen real estate on the graphical tool bar at the top. Other people certainly will have different opinions.
 
You must log in or register to reply here.
Back
Top