python installed in devx...sfs
gyrog opened this issue · 15 comments
I don't undersand the logic of installing python to the devx...sfs.
If I develop a program using python, it is then a waste of time providing it to the Puppy public,
since without downloading and loading the devx...sfs they can't run my program.
(Like java needs a jre.)
I hope someone can demonstrate that I am wrong.
It's been like this for years. You can't put any application written in Python in the main SFS unless you move Python from devx to the main SFS. And users can't run any application written in Python unless they have devx loaded.
(I moved Python to the main SFS in dpup builds, so I can include Blueman)
Moving python3 to the main SFS seems like a good move to me.
Moving python3 to the main SFS seems like a good move to me.
In which Puppy?
@dimkr,
I would like this in all Puppies if it could be done at a woof-ce level.
Hmmm... I should probably make requests in the appropriate forum topic of particular Puppies.
There are may things to like about programming in Python, but there is one in particular that is attractive:
Code can be distributed as ".py" files, which means every user has a copy of the source, like bash scriipts, but unlike languages that compile to binay e.g. C, or vala, or genie.
Hmmm... I should probably make requests in the appropriate forum topic of particular Puppies.
Sadly, yes.
Blueman is written in Python so Python is already in the main SFS of dpup, jammy64 and F96.
(I see some Puppy releases include Python 2 in devx, it's probably a waste of space - the world has moved on)
Moving python3 to the main SFS seems like a good move to me.
I think the issue is containers and container contents and distribution methods.....
The .iso is a container which is provided for download.
The .iso contents are .sfs files which are generally loaded automatically by the boot process.
The devx is traditionally an .sfs file which is not included in the .iso container but is made available for download by being adjacent to the .iso
The contents of the main puppy.sfs have to date been selected so as to not depend on some large infrastructure components such as Python & Qt & SystemD & SQL for example. Some large infrastructure such as LLVM has had to be included in the puppy.sfs but in a cut-down version implemented by the packages-templates mechanism - also applies to Perl.
There is currently a "debate" on whether large apps such as Samba should be included in the puppy.sfs.
For LxPupSc (local build) I am now providing Samba as a cut-down .sfs built from Slackware components which is included in the .iso but is not automatically loaded - some user action is needed helped by prompts.
If Python has to be included solely for Blueman then the traditional Puppy approach would have been to re-implement a Puppy-specific app which did not have the Python dependency. Maybe these days are long past.
Maybe Python should be moved out of the devx and included in the .iso container as an optional .sfs - either manually installed if needed or made into a pdrv to be automatically installed if copied over to the frugal install directory. Maybe in a similar fashion Samba should be an sdrv..... Qt a qdrv..... SQL a ddrv (for database).....
If Python has to be included solely for Blueman then the traditional Puppy approach would have been to re-implement a Puppy-specific app which did not have the Python dependency. Maybe these days are long past.
IMO this idea of a "traditional" Puppy needs to go away, because it produces crippled distros. Putting something in devx because it's needed to build preinstalled package A, although it's needed to run packages B and C, doesn't make any sense.
I'm open to the idea of replacing Blueman with a lighter alternative that isn't written in Python, but I don't see any viable alternative to Blueman at the moment (all alternatives are big, tied to a specific DE and part of it), and there's a very good chance that this will increase size a lot (because applications written in Python are scripts, it's mostly text and the compression ratio is great). Plus, the Python dependency is shared with other things written in Python, like gdebi, so Python can't be dropped anyway.
Save few MBs in [enter distro name here] but provide users with a distro that doesn't support Bluetooth can't run many applications out of the box (yt-dlp, Blueman, ...) ... I think this is an easy decision.
Python & Qt & SystemD & SQL for example. Some large infrastructure such as LLVM has had to be included in the puppy.sfs but in a cut-down version implemented by the packages-templates mechanism - also applies to Perl.
My dpup builds are 100% built from .deb packages and packages built from source. Believe it or not, the packages needed to build geany, abiword, gnumeric, mpv [... basically, all traditional Puppy applications and then some] are not that big. devx is pretty small once things like Perl and Python are just moved to the main SFS instead of having one half-broken copy in the main SFS and the entire thing in devx. If most users need devx anyway, a separate devx SFS is useless: this "tradition" wastes space due to duplicate packages and the users that decide not to switch to another distro where everything "just works" have to download and load devx manually, only to get some application to run.
There is no point in programming a utility in Python, if Python exists only in the devx...sfs, or any other .sfs file that is not included and loaded auatomatically for ordinary users.
So, is their any value in including it in the devx...sfs at all?
I have been thinking of programming some of my own alternatives for displayiing some dialogs in FrugalPup that can cope with variable length text messages, (the result of translation), a lot better than yad.
These programs would depend on access to a full implementation of Gtk libraries.
(I discount C and C++ because too much time is spent on coding house-keeping, that could be done by a compiler.)
As a programming language, Python is attractive, but that would seem to be a waste of time.
I'm left with things that compile to binaries, e.g. either of the gnome languages, vala or genie, which are perhaps a little obscoure.
As a programming language, Python is attractive, but that would seem to be a waste of time.
If Python is the best option, maybe just do your thing and let users know your application won't work in a Puppy that doesn't have Python?
I'm left with things that compile to binaries, e.g. either of the gnome languages, vala or genie.
More options:
- Rust (pro: the hot new thing, con: the hot new thing and big executable)
- zig (pro: interoperability with anything written in C but in a modern language, con: many of the disadvantages of C)
- Go (pro: no need to install anything to run your executable, con: big executable)
- Any scripting language of your choice including Python, but implement the application logic as REST API and use HTML+browser for the UI
@dimkr,
if only things were that simple.
My project is to implement an i18n version of FrugalPup as per this message on the forum:
Post by thinkpadfreak » Mon Jan 09, 2023 6:06 am Hello. Frugalpup is included in recent puppies. So I suggest it should be made ready for internationalization / localization for those whose native language is not English.
I don't think it's a good idea for FrugalPup v40, to suddenly require Python, when all previous English only versions have gotten by fine with only yad dialogs.
Pick your battles, the number of active Puppy developers is probably <=5. If you need to rewrite in Python to make development easier and nobody's life depends on a timely release of this v40, maybe it's worth it.
Sorry if I'm harping, but either include a Python in Puppy...sfs or have no Python anywhere, having it in devx...sfs is pointless.
I suspect Python is in the devx because it is a dependency of some elements of the toolchain ... it isn't in the main sfs because a. it is big and b. puppy was deliberately constructed not to need it....
Each system build determines where it is to be included by the entry in the build-specific DISTRO_PKGS_SPECS
was
It was a good decision back then, but times have changed.
because it is a dependency of some elements of the toolchain
itstool is written in Python and it's needed to build gnumeric and other packages. But that's just one example, there's more.
Today, many applications are written in Python or depend on Python (for example, hexchat has a Python scripting plugin). In many old computers, yt-dlp is the best way to watch videos from YouTube, and it's a pity not to be able to run it and the various video players that integrate with it (including mpv).
I have a solution.
When I release a utility written in Python3, I will also release a Python3 containing all the modules required to run the utility.
(Even when a Python3 interpreter is available, I find some modules required by the code I am writing, are not included.)
I currently have working 32bit and 64bit Python3 interpreters as AppDirs, I may release them as .sfs files.