[Catalog-sig] an immutable mirror of PyPI

"Martin v. Löwis" martin at v.loewis.de
Tue Jul 5 20:42:30 CEST 2011

> It seems that "not wanting to support software" is somehow connected
> to "not providing the software for download" in people's minds

Indeed. As a package author, I find that highly plausible. If the
software is no longer available anymore, people will stop using it,
so they won't bother me with support requests.

> this
> is exactly the reason why the maintainer of the package that triggered
> this discussion for me removed these older versions. And as a result
> he probably got more support issues than if if he'd left them around.
> :)

That's only temporary. When the dust settles, people with either move
to a newer version, or use something else altogether.

> You can also see this as a historical record or version control issue.
> Just because version 0.7 is in a version control system somewhere
> doesn't mean that the developers are going to support this version.

In free software, you have to support stuff when people contact you.
So removal is the easiest way to reduce the amount of time you have
to spend for support.

> But in this case, I don't see developers argue there that this
> historical version should therefore be removed.

That's because the users that cause support effort don't check
out the software from the repository - those that do check out
old versions don't contact you for support.

> With dependencies, my project in version control (or in released
> tarball form) has a dependency on an external system. I could instead
> check all dependencies into my version control system, or I could
> depend on an external system with more guarantees.

For example, you could depend on the source control system of the
software you are depending on.

> That's the feedback
> I'm getting: either use a system with more guarantees such as a Debian
> release, or check everything into my own version control system. But
> this isn't always feasible.

I can understand the problem. I'm just telling you that the solution
you propose is an unacceptable interference with the freedom of the
package authors (and this comes from somebody who thinks that a rating
system is *not* an unacceptable interference with that freedom).

> * debian might not have my dependencies available yet, or a different version,

I won't give advice to you, just saying what I do: use the version
in Debian. If it doesn't work, adjust your code until it does.

If something isn't in Debian, I try to work without the package,
possibly rewriting some of the functionality. If the amount of
rewriting would be too large, I make an exception and install
from PyPI. When doing so, I try to find a version whose dependencies
can again be satisfied from PyPI.

> * I want to hack on the stable and development version of my project
> without having to install a virtual linux for each to make sure the
> debian dependencies are right

I try to depend only on released version of software, both for stable
and development versions, and preferably on the same version of the
dependency. So I can use a single Python installation.


More information about the Catalog-SIG mailing list