Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #14097 > unrolled thread

Need a hand with tiledb-python

Started byDirk Eddelbuettel <edd@debian.org>
First post2022-05-10 13:20 +0200
Last post2022-05-14 03:10 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.debian.maint.python


Contents

  Need a hand with tiledb-python Dirk Eddelbuettel <edd@debian.org> - 2022-05-10 13:20 +0200
    Re: Need a hand with tiledb-python Neil Williams <codehelp@debian.org> - 2022-05-10 15:10 +0200
    Re: Need a hand with tiledb-python Dirk Eddelbuettel <edd@debian.org> - 2022-05-14 03:10 +0200

#14097 — Need a hand with tiledb-python

FromDirk Eddelbuettel <edd@debian.org>
Date2022-05-10 13:20 +0200
SubjectNeed a hand with tiledb-python
Message-ID<Elw4h-ex43-1@gated-at.bofh.it>
Hi all,

I look after the 'tiledb' (a C++ library) package and the 'tiledb-r' package.
I also effectively maintain 'tiledb-python' but I am running into some issues
there.  I do know a little bit of Python and have (co-)maintained two or
three packages there for decades but this one stumps me.

Larger context is that that upstream is fairly heavy user of Conda and used
to a lot of explicit version pinning.  This creates issues for us here as the
build wants to leave the chroot/pbuilder to match those pins.  Adam (CC'ed)
who set this up initially already patched some calls out (for example sphinx
docs are now local). The 'delicate' bit is that I actually work at TileDB ;-)
and don't want to have a fight over the upstream choice (so I didn't bug my
colleague yet). Upstream use is upstream use, but Debian packaging also has
its rules.

The packaging is at
   https://salsa.debian.org/python-team/packages/tiledb-py
(and for historical reasons I also have one at
   https://salsa.debian.org/edd/tiledb-py
which it is behind) and I would *really* appreciate it if someone could take
a look.  I tried patching requirements_dev.txt and misc/requirements_wheel.txt
but am apparently out of my depth here. I reached out to Adam (CC'ed) but he
is busy too.  We all know how it goes.

Please CC me on follow-ups as I am not subscribed to debian-python.

Thanks,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

[toc] | [next] | [standalone]


#14098

FromNeil Williams <codehelp@debian.org>
Date2022-05-10 15:10 +0200
Message-ID<ElxMJ-ey9a-3@gated-at.bofh.it>
In reply to#14097

[Multipart message — attachments visible in raw view] — view raw

On Tue, 10 May 2022 06:13:33 -0500
Dirk Eddelbuettel <edd@debian.org> wrote:

> Hi all,
> 
> I look after the 'tiledb' (a C++ library) package and the 'tiledb-r'
> package. I also effectively maintain 'tiledb-python' but I am running
> into some issues there.  I do know a little bit of Python and have
> (co-)maintained two or three packages there for decades but this one
> stumps me.
> 
> Larger context is that that upstream is fairly heavy user of Conda
> and used to a lot of explicit version pinning. 

First, I would strongly recommend enabling Salsa CI - helps those
trying to help you by having public build logs etc.. Also, use the
lintian-brush package (against a git clone in a SID chroot/vm) to trim
out some of the versions listed in the build-dependencies. (Debian BD
don't need to refer to versions not in the archive, so a straight copy
from setup.py isn't useful.)

I've now done a number of packages where upstream rely on Conda. There
is no simple solution - the best option is to aggressively patch out
the key conditionals which determine how Conda support interferes with
Debian packaging & patch out the overly strict version handling.

New support in pybuild may help your specific package but I've found it
easier to patch in a setup.py as that makes it more straightforward to
support a backport to buster. Depends on your needs.

The specific packages tend to also use SCons which complicates things
further - there isn't a direct example in my list.


> This creates issues
> for us here as the build wants to leave the chroot/pbuilder to match
> those pins.  Adam (CC'ed) who set this up initially already patched
> some calls out (for example sphinx docs are now local). The
> 'delicate' bit is that I actually work at TileDB ;-) and don't want
> to have a fight over the upstream choice (so I didn't bug my
> colleague yet). Upstream use is upstream use, but Debian packaging
> also has its rules.

Patches do not have to go upstream when the changes are to make the
package work in Debian instead of Conda. 

> 
> The packaging is at
>    https://salsa.debian.org/python-team/packages/tiledb-py
> (and for historical reasons I also have one at
>    https://salsa.debian.org/edd/tiledb-py
> which it is behind) and I would *really* appreciate it if someone
> could take a look.  I tried patching requirements_dev.txt and
> misc/requirements_wheel.txt but am apparently out of my depth here. I
> reached out to Adam (CC'ed) but he is busy too.  We all know how it
> goes.
> 
> Please CC me on follow-ups as I am not subscribed to debian-python.
> 
> Thanks,  Dirk
> 
> -- 
> dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
> 


-- 
Neil Williams
=============
https://linux.codehelp.co.uk/

[toc] | [prev] | [next] | [standalone]


#14101

FromDirk Eddelbuettel <edd@debian.org>
Date2022-05-14 03:10 +0200
Message-ID<EmOs9-fjOv-5@gated-at.bofh.it>
In reply to#14097
I have now orphaned the package [1] as this one needs more attention that I
can currently give it due to 180+ other packages I have, and other work and
open source commitments.

Dirk

[1] https://bugs.debian.org/1010953

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.maint.python


csiph-web