Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A slimmer python #581

Open
3 tasks
hmaarrfk opened this issue Sep 11, 2022 · 6 comments
Open
3 tasks

A slimmer python #581

hmaarrfk opened this issue Sep 11, 2022 · 6 comments
Labels

Comments

@hmaarrfk
Copy link

Comment:

I'm wondering if there is enough enthusiasm for having a slim python build. My main motivation is to help ensure that downstream packages that depend on python, also declare the dependencies they have on other libraries. The ones that come to mind are:

  • readline
  • sqlite
  • tk

I'm not sure about the implementation, but maybe we can have a behavior similar to pip, where during the build process they aren't pulled in automatically, but for regular users they are? I know that the pip feature is engrained pretty deep into conda, so maybe it isn't that desirable to use it, but the behavior:

  • At build time, maintainers might have to specify python-readline, python-sqlite, python-tk as part of their dependencies.
  • At environment making time, maybe those are all pulled automatically?

With non-python packages, this has typically resulted in the creation of a "core" package. This would mean that the dependency graph might look like

           /----- python-readline ----\------------------> readline
          /------ python-sqlite -------\-----------------> sqlite
python ------------------------------------ python-core
          \-------python-tk------------/-----------------> tk
```
with `tk`, `sqlite` and `readline` being removed as dependencies from `python-core`.


PS. I know this conversation is quite cyclic in nature but I figured it is time to revive it.
@peterroelants
Copy link

I rencently have been pondering something similar when I noticed that the conda-forge Python interpreter is about 50MB larger than the python-minimal interpreter from Debian/Ubuntu.

Let me know if this is a duplicate question: #586

@jakirkham
Copy link
Member

Yeah it sounds like the same thing. Let's consolidate into this issue. If you spot anything else that hasn't already been suggested for splitting above, please feel free to add that as a comment here. Thanks! 🙏

@peterroelants
Copy link

From Duplicate: #586

Comment:

Would it be of interest to provide a python-minimal package in conda-forge providing a minimal installation of Python, similar in spirit to e.g. the Debian/Ubuntu python3.10-minimal packages?

I noticed that the python3.10 lib directories differ about 50MB in size:

  • apt install python3.10-minimal: 22M /usr/lib/python3.10/
  • micromamba create -n py310 --channel conda-forge python=3.10.*: 70M /root/micromamba/envs/py310/lib/python3.10

The conda-forge python package contains things like turtledemo, tkinter, lib2to3 which are not typical requirements and are not in python3.10-minimal.

@jakirkham
Copy link
Member

Do turtledemo or lib2to3 take up significant space?

@hmaarrfk
Copy link
Author

hmaarrfk commented Oct 8, 2022

about 0.5MB and 1.2MB respectively it seems.

@jakirkham
Copy link
Member

IMHO lib2to3 still feels pretty core to Python. Some packages rely on it in their build processes.

No strong feelings on turtledemo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants