• Need a hand with tiledb-python

    From Dirk Eddelbuettel@21:1/5 to All on Tue May 10 13:20:01 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Neil Williams@21:1/5 to Dirk Eddelbuettel on Tue May 10 15:10:01 2022
    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/

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEf3HB6ceOc10DYMbM8WfkPIFDtoIFAmJ6YhgACgkQ8WfkPIFD toIA6BAAwCCMk3wCTir/IZRgALxZ+dyVjp9DJG5KnWIDOkkErTwl8jiGJkCCt8BE VOYXD0qZl5mSyRvbz2VSy4XgKZAxZdTa9InSqytZtczP53H4Z13mAu1J6B/UUipX vsOxZ/AQM+zfkqzH0M89MrG9f/k6IN/lWIooD/NjrfYQs07rnRtNS3jr0Qvt16l2 fiN0wKr6cauyuGRLmd+NzV6fEKCcjHvXXPywQuOT02XYGj3TAwY97dvG22nedhF4 nGfsjpDzXNkqt76CGl1VHuC2Jal/u8nK/4U8Mjxxuo0r/NNndDha2TSoUeBnOKzD 3MxMtdrgzXvyME5zh8NOgk3BFVdF6kbHWqp1eADBYB3ab5SKIZ9usyL1UUQPv5tj YR3BqSC8+utv97O9a73qCJ2VhiDTspOs+QzCI/nq/Vd7pvOUPZBsmHIudP4E/Ksb vPrvM3+8xhPbPXRfvQpW8klnQP/5+9OXdWm9Yg5TeO1SMFEhDWuB6UBUIxVaQzWL xR/Ts7uIGu+3xxrrmrPOEJNZDqxq7+OAWt2Sp65h0Ektv6ej5l4P8wdSyr5EQS2L b3GhFPtDUlelU6pnMWjhay2FKn2Sui4C6nY1ujl79RvaDBrXZktRgNwGvGRFcHS2 vXwHBnWa9jeK6oNtI0mRi5cnRnDBJHasZbyaIM1+UHmLanbqDGM=
    =OXy7
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dirk Eddelbuettel@21:1/5 to All on Sat May 14 03:10:01 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)