#779006 RFP: devpi -- PyPI-compatible package server

Package:
wnpp
Source:
wnpp
Submitter:
Ben Finney
Date:
2025-09-01 09:17:03 UTC
Severity:
wishlist
#779006#5
Date:
2015-02-23 00:46:31 UTC
From:
To:
* Package name    : devpi
  Version         : 2.1.0
  Upstream Author : Holger Krekel <holger@merlinux.eu>
* URL             : http://doc.devpi.net/
* License         : Expat
  Programming Lang: Python
  Description     : PyPI-compatible package server
    DevPI implements a PyPI-compatible package server for Python
    packages.
    .
    Use cases include: a local PyPI mirror server; uploading,
    testing, and staging for the package release process; replication
    and failover for package servers.

The source package will build the following binary packages:

    devpi-server -- PyPI-compatible package server
    devpi-web -- PyPI-compatible package server (web interface)
    devpi-client -- PyPI-compatible package server (command-line tool)
#779006#10
Date:
2015-03-02 22:40:32 UTC
From:
To:
As reported in upstream's BTS, the source code has no single version
<URL:https://bitbucket.org/hpk42/devpi/issue/215/consistent-version-for-all-devpi>.

This makes packaging needlessly difficult: there is a lot of metadata
commonality shared by components, but there are no releases with
a unifying version.

Postponing this packaging work until upstream bug #215 is fixed. When
there is a reliable release policy to have upstream source with a single
changelog and a single version, packaging will become feasible.
#779006#17
Date:
2015-03-28 00:00:00 UTC
From:
To:
Control: retitle -1 RFP: devpi -- PyPI-compatible package server
Control: noowner -1

Upstream have closed that bug report, declaring that they want to
continue with a single VCS *and* differently-versioned components.

(My sigmonster has chosen an appropriate aphorism for this message.
Good sigmonster, have a cookie.)

Since upstream have declared commitment to the overcomplicated release
scheme, I am convinced it is not worth my time to continue with
packaging work for devpi.

Leaving this bug report open in case someone else wants the hassle of
working with upstream's release policy.
#779006#26
Date:
2015-07-19 16:49:16 UTC
From:
To:
I'll go for that. I agree, the development structure not so convenient for
the maintainers. Might need multiple source packages, we'll see.

DS
#779006#41
Date:
2020-03-15 04:53:59 UTC
From:
To:
Hi Python Team

Can I join both the DPMT and PAPT to help maintain devpi (and its
associated subprojects)?
I've read both the DPMT and PAPT policies and accept them.
My salsa login is aragilar-guest.

My plan for devpi is to update devpi-common to the latest release, then
work down the list of devpi projects.
I plan on putting the projects under PAPT (apart from devpi-common), unless
there are other suggestions?

James

P.S. I've CC'd in the current ITP bugs for devpi, there will probably be
more as I package further projects.
#779006#46
Date:
2025-09-01 07:41:27 UTC
From:
To:
According to upstream the default Python version is 3.10 and testing
started with 3.11. As both versions are no longer part of Debian unstable,
this software does not seem to be suitable for Debian, thus closing this
RFP.

   Thorsten