tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Why do we need Python sub-modules?



On Mon, Jun 04, 2018 at 06:00:00PM +0200, Adam Ciarciński wrote:
> >> In couple of days I would like to change all Pythons to include
> >> missing modules: curses, curses_panel, elementtree, sqlite3, pyexpact,
> >> readline, spwd, Again, Python modules do not list them as dependencies
> >> (why would they?), but assume they exist, so it is hard to properly
> >> package Python with the current setup.
> >> 
> >> I will remove module packages (py-readline, py-curses, ...) and bump
> >> revision for packages that depend on them.
> > 
> > The really big question is why we split this off, if those reasons still
> > hold, and what the alternative approaches are.
> > 
> > It seems a bit much for the core langauge to have these dependencies,
> > and I'm guessing we have them split to avoid them.  Your point about
> > programs not declaring them because they are supposed to be part of the
> > language is valid, but it seems a python/python-base or
> > python-full/python split with dependencies would solve that while
> > allowing those who want to be lean to be continue doing so.
> > 
> > In particular, python is under a permissive license, and while it's not
> > entirely clear, linking in real readline would seem to move it to GPL.
> > Or maybe it's just a raedline module that is merely aggregated...  Can
> > you explain if there are any licensing impacts?
> > 
> > Overall this feels like a big change so I think we should allow for
> > discussion.
> 
> Currently devel/readline is marked as build dependency for every Python.
> Why not using is as full dependency and provide users with command
> history in Python interpreter? I've seen questions popping here and
> there, how to enable history in Python provided by PkgSrc? We should
> provide readline. That's what is expected.

It is a build dependency, because it doesn't work otherwise due to
misfeatures of the configuration system of Python. Frankly, if you want
to have good command history and stuff, you should be using ipython
anyway. I don't see a good reason for handling readline different from
the rest.

> As for other modules:
> 
> curses/curses_panel - should depend on system library (most systens provide curses support); in worst case, there will be ncurses (MIT licence).

Yes and ncurses is already not that small.

> elementtree/pyexpat - is required for correct XML support; try:
> 	python -c "import xml.etree.ElementTree as ET; ET.fromstring('<x />')"
> 	without textproc/py-expat being installed; both modules depend on textproc/expat (MIT licence); it is double wrong to separate them.

Not true, the minidom implementation works quite well for a lot of use
cases.

> spwd - only for Linux to access shadow password files; no dependencies.

I don't care about it at all. Never had a use case for it, doesn't do
anything significant either.

> sqlite3 - many Python packages assume it is built-in; I plan to include
> it, but I can keep it excluded; depend on databases/sqlite3 (public-domain licence).

Again, sqlite is quite a heavy dependency. 

Just leave things as is, please.

Joerg


Home | Main Index | Thread Index | Old Index