Python3x vs Python3xFull # package name change in 2016 vs standardized semantic - adopt to standard python semantic

Development
#1

The difference between Python3x vs Python3xFull was discussed in some place along the time

To solve that topic on the one hand and on the other keep it in like the standard semantic of Python and the user community we should name the packages as what they are.

Like @vcunat proposed in 2016, it would be best to call

  • the minimal version of python[38] with a suffix like python[38]-slim (currently misleadingly called pkgs.python38)

  • means that the python derivative most equivalent to the original Python[38] https://www.python.org/) should be referenced with pkgs.python38 (not a minimal variant)

in nixpkgs
pkgs= import (fetchTarball https://github.com/nixos/nixpkgs/archive/nixos-20.09.tar.gz) {}

pkgs.python38
(e.g. does not include tkinter)
vs:
pkgs.python38
(includes pkgs like “bluez” (“libX11”) “tcl” “tk” “xorgproto” to be an equivalent Python3.8)

Other examples for python semantic can be seen at docker
python:3.8
(includes the packages of Python3.8)
vs
python:3.8-slim
(e.g. does not include tkinter)

currently with the slim python version called as python38
the interpreter is lying to you
→ that is no foundation to build code on top (this is a huge obstacle if you what you use it e.g. in production)

The issue needs to be fixed to have the chance to spread out python development in nix/nixos.

#2

No. The extra modules are seldom used and take up space and for that reason removed. The default in Nixpkgs is therefore the “slim” version. Changing this would cause people to use the fat version for no reason.

python3Full was at some point non-existent. It should be used in Nixpkgs only when absolutely necessary.

1 Like
#3

Nobody would have to use the original (you call it fat) Version of Python3.8

  • because there would be pkgs.python38-slim

Fact check:
The difference in SIZE of pkgs.python38 and pkgs.python38Full is 3.4M (that is “fat” in your opinion)

  • for micro services there are some people who want to get rid of this “overhead” - but those would use e.g. alpine anyways
  • Nobody who wants to create a Data Science development environment with a sizes up to ~10GB (pure docker) will notice or even care about this <3.4M

But the truth is that these 3.4M cannot be called overhead because in an environment it’s getting vanished with all the needed dependencies of other python dependencies (for , stats/simulation, deep learning, visualization, geo-spatial, web dev , vision, audio, …, R, rPackages )

  • e.g. the size of this random example bis 6.4M with and without python38[Full] (what surprises me, too - please validate it as well)

where is the place to find those statistics about nixpkgs? Sounds interesting!

How can you know about the reason of the people?

only because till now the focus of development with python in nixos was not focuses to development with UI components or interactions does not means that it is changing in the present/future, right?

Lets be open and keep up to the “user expected” standard

  • Agile Principle 2: Welcoming changing requirements

If people try nixpkgs and expect python3.8 (the original Python) BUT using pkgs.python38 (the nixpkgs minimal version without the expected feature)
→ their build will fail and they won't use nix/nixpgs
→ so statistics is not all you should think about [because it reflects only the behavior of the past]

can you explain why you are so desperate about the original Python interpreter/ python3Full as its derivative in nixpkgs?

#4

python development in nixos could have a great impact in areas like data science

  • but NOT if python in it’s core is lying/is a bug - which is the status quo

How would you automate pypi and/or conda-forge package conversion to nixpkgs if your python interpreter [as a silm version] gives wrong results regarding builtin installed modules/packages?

Take a look around:

How do you think python on nixos should develop strategically?

#5

That was a commentary on the general state of python packages. In general, the release management discipline is very low. There’s a few fundamental packages like requests which do an exceptional job at semantic versioning and providing an amazing user experience. But the average python package includes many unstable packages, and publishes breaking changes every few weeks or months.

In data science, this is worsened because the number of packages used in a normal machine learning project is massive.

How do you think python on nixos should develop strategically?

The python ecosystem needs to figure itself out. And not treat release management as an afterthought.

Hosted by Flying Circus.