Create pypi source distribution or split repository into two: One for `spandrel` and one for `spandrel-extra-arches`

[alsa64]

This would simplify packaging spandrel for various package managers like nix. Since the version number of spandrel and spandrel-extra-arches aren´t the same (0.3.4 and 0.1.1 right now), it would also allow for tracking them in separate tags.

Ideally the pyproject.toml file would be in the root of each repository.

[joeyballentine]

I don't really see why it's an issue. Just clone the repo, cd into each lib individually and treat it like its own package

[alsa64]

At the moment, I use a handwritten package for spandrel, while it works, the automated package generators tend to fail as the pypi version is only available in binary form (see no Source Distributions warning) or because right now this is a monorepo.

In case someone needs it, here's a nix package for the current version of spandrel:

{
  lib,
  buildPythonPackage,
  fetchFromGitHub,
  python3,
}:
let
  p_version = "0.3.4";
  repo = fetchFromGitHub {
    owner = "chaiNNer-org";
    repo = "spandrel";
    rev = "v${p_version}";
    hash = "sha256-cwY8gFcaHkyYI0y31WK76FKeq0jhYdbArHhh8Q6c3DE=";
  };
in

buildPythonPackage {
  pname = "spandrel";
  version = p_version;
  pyproject = true;

  src = "${repo}/libs/spandrel";

  nativeBuildInputs = with python3.pkgs; [
    setuptools
    wheel
  ];

  propagatedBuildInputs = with python3.pkgs; [
    torch
    torchvision
    safetensors
    numpy
    einops
    typing-extensions
  ];

  pythonImportsCheck = [ "spandrel" ];

  meta = with lib; {
    description = "Spandrel gives your project support for various PyTorch architectures meant for AI Super-Resolution, restoration, and inpainting. Based on the model support implemented in chaiNNer";
    homepage = "https://github.com/chaiNNer-org/spandrel";
    license = licenses.mit;
    maintainers = with maintainers; [ ];
  };
}

And spandrel-extra-arches (not the differing version of the package and the repo tag):

{
  lib,
  buildPythonPackage,
  fetchFromGitHub,
  python3,
  spandrel,
}:
let
  spandrel_version = "0.3.4";
  repo = fetchFromGitHub {
    owner = "chaiNNer-org";
    repo = "spandrel";
    rev = "v${spandrel_version}";
    hash = "sha256-cwY8gFcaHkyYI0y31WK76FKeq0jhYdbArHhh8Q6c3DE=";
  };
in

buildPythonPackage {
  pname = "spandrel-extra-arches";
  version = "0.1.1";
  pyproject = true;

  src = "${repo}/libs/spandrel_extra_arches";

  nativeBuildInputs = with python3.pkgs; [
    setuptools
    wheel
  ];

  propagatedBuildInputs = [
    python3.pkgs.torch
    python3.pkgs.torchvision
    python3.pkgs.safetensors
    python3.pkgs.numpy
    python3.pkgs.einops
    python3.pkgs.typing-extensions
    spandrel
  ];

  pythonImportsCheck = [ "spandrel_extra_arches" ];

  meta = with lib; {
    description = "This library implements various PyTorch architectures with restrictive licenses for spandrel.";
    homepage = "https://github.com/chaiNNer-org/spandrel";
    license = licenses.mit;
    maintainers = with maintainers; [ ];
  };
}

[joeyballentine]

Ok so the real fix is that we need to include source distributions. Thanks for pointing that out

[alsa64]

No problem, certainly not a huge issue, this mostly affects people using nix for development using tools to generate packages from a requirements.nix file, with nix being a niche community, the intersection between nix and spandrel users is probably relatively small.

Out of curiosity, why the monorepo? Is it because the extra arches were historically part of the main package to carry forward old issues?

[joeyballentine]

Out of curiosity, why the monorepo?

Simplicity. They were originally one package, and since they share common code it's a lot easier to be able to make changes to both at once than to have to deal with updating spandrel first then making subsequent changes to the extra arches package. The only reason they were split out was for licensing reasons, so this way keeps it closer to having it as one package while actually publishing it as two.