Re: texlive organization on netbsd

As far as python and pip is concerned, I think pkgsrc should contain only python packages which depend on non-python ones already available. The packages which are easily to install using pip should be used with venv, which to my knowledge is the recommended python development method anyway and will not mess with foreign files present in the pkg tree. This approach can help minimise the number of py- packages in pkgsrc. I am not sure about how npm works, whether there is an equivalent to venv; as far as texlive, I only have used the meta packages for whatever needs I've had over the years.

I think something along these lines should be preferable - in the presence of a native package installer capable of working for an individual non-root user, to try to minimise the corresponding content in pkgsrc. The other day I tried to build py-matplotlib with the graphical interfaces with pkgsrc on an OpenSUSE Tumbleweed system, everything in the build went right, but at the end no graphic window appears when the test program is invoked... The native 'pip3 install matplotlib' worked of course.

On Tue, 12 Jun 2018 at 12:31 Mayuresh <mayuresh%acm.org@localhost> wrote:

On Tue, Jun 12, 2018 at 01:07:42PM +0200, Joerg Sonnenberger wrote:
> On Tue, Jun 12, 2018 at 07:45:56AM +0530, Mayuresh wrote:
> > We have done the right thing for python by supporting pip, and similarly
> > npm for nodejs in pkgsrc. Wonder why not do the same for texlive.
>
> I have no idea what you even mean here. PIP is not integrated into
> pkgsrc. It doesn't interact with the system in any meaningful way.
> Same for NPM. Both violate certain core principles of pkgsrc. With
> tlmgr, you get all that and the additional fun of no dependencies.

I was referring to devel/py-pip being present in pkgsrc.

Simple point is, I could use the python packages I needed, which weren't
in pkgsrc as soon as I needed them thanks to pip being provided by pkgsrc.

It is impracticable to map every single python/R/texlive/nodejs package to
pkgsrc. Their sheer count is intimidatingly large and ever growing.
Creating them and keeping them up to date over time would incur a lot of
effort.

The package managers of python/R/texlive/nodejs could have the problems
you mention and if there are better alternatives to them they are most
welcome. But we might as well begin with whatever we have. And we have
begun by having devel/py-pip, lang/npm and may be something for R that I
am not aware of.

Why shouldn't we extend the same logic to tlmgr?

Mayuresh