Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dead batteries packages: standard-aifc, standard-sunau, standard-chunk, and audioop-lts #29400

Merged
merged 3 commits into from
Mar 12, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 46 additions & 0 deletions recipes/audioop-lts/meta.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
{% set name = "audioop-lts" %}
{% set version = "0.2.1" %}
{% set python_min = "3.13" %}

package:
name: {{ name|lower }}
version: {{ version }}

source:
url: https://pypi.org/packages/source/{{ name[0] }}/{{ name }}/audioop_lts-{{ version }}.tar.gz
sha256: e81268da0baa880431b68b1308ab7257eb33f356e57a5f9b1f915dfb13dd1387

build:
noarch: python
script: {{ PYTHON }} -m pip install . -vv --no-deps --no-build-isolation
number: 0

requirements:
build:
- {{ compiler('c') }}
- {{ stdlib('c') }}
host:
- python {{ python_min }}
- setuptools
- pip
run:
- python >={{ python_min }}

test:
imports:
- audioop
commands:
- pip check
requires:
- python {{ python_min }}
- pip

about:
summary: LTS Port of Python audioop
license: EPL-2.0
license_file: LICENSE
home: https://github.com/AbstractUmbra/audioop

extra:
recipe-maintainers:
- bmcfee
40 changes: 40 additions & 0 deletions recipes/standard-aifc/meta.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
{% set name = "standard-aifc" %}
{% set version = "3.13.0" %}

package:
name: {{ name|lower }}
version: {{ version }}

source:
url: https://pypi.org/packages/source/{{ name[0] }}/{{ name }}/standard_aifc-{{ version }}.tar.gz
sha256: 64e249c7cb4b3daf2fdba4e95721f811bde8bdfc43ad9f936589b7bb2fae2e43

build:
script: {{ PYTHON }} -m pip install . -vv --no-deps --no-build-isolation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one can probably be noarch, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle yes, but see my comment/question in the main PR thread about noarch vs selectors #29400 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, missed that, you need to set the min python variable, add

{% set python_min = "3.13" %}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This effectively means that any downstream package that depends on these would have to stop using noarch because we can't use selectors in the requirements spec.

Ah, I misread. OK. If this module is done "right" you probably can install it without clobbering, it will become a stub. If not, you will have to keep this as-is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this module is done "right" you probably can install it without clobbering

To clarify, do you mean the implementation of the module, or the packaging of the module?

My understanding is that the module code itself is a direct extraction from old standard lib code, and doesn't have the smarts to stub itself out. At the same time, I don't think the deadlib maintainers are open to contributions that would add the stub logic, since they want to keep the code essentially as archival.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick follow-up:

  • I checked the deadlib aifc source, and verify that it's not doing anything smart to detect collisions (ie that it's running on an old python)
  • OTOH, I also installed it via pip in a python 3.7 environment, and it seems to work. That is, import aifc hits the standard lib module first and does not try to load the deadlib version. I expect that even if it did hit the deadlib version, it would still work, but I'd rather not chance it.

This then raises the question: is it legit to package these deadlibs as noarch that can be installed on any python version? Maybe that's a question for the deadlib maintainers?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This then raises the question: is it legit to package these deadlibs as noarch that can be installed on any python version? Maybe that's a question for the deadlib maintainers?

Giving the fact that is clobbers existing files? No. It is better too sacrifice noarch advantages here. Let's keep these as is. Thanks for the clarifications.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Giving the fact that is clobbers existing files?

It's not clobbering the existing files, but "correct" behavior (ie using the standard lib implementation instead of the external package) depends on the module import search order. While this is (to my knowledge) well-defined, it does make me a little nervous.

It is better too sacrifice noarch advantages here.

For these packages, that's fine. I'm more concerned about the downstream packages that may want to stay noarch and have these deadlibs as dependencies if needed. This is where I'm stuck, and I don't see a simple path forward with the usual packaging pipeline.

I do wonder if it's possible to do something clever here: what if these deadlibs are not built as noarch, and we create stub packages for python <=3.12 that do not install anything? For 3.13+ the packages would install as we currently have them in this PR.

This would make it so that the downstream dependents could still be noarch and depend on these libs, but installing, say, standard-aifc in a 3.12 environment would act as a no-op.

Is such a thing possible?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this is (to my knowledge) well-defined, it does make me a little nervous.

Same.

This is where I'm stuck, and I don't see a simple path forward with the usual packaging pipeline.

Yeah, better this one "arched" and many other noarch.

Is such a thing possible?

Probably. Not sure if it is worth it though. IMO, we should fix the "semi-arch" concept so we can do things like this as noarch moving on. However, that is a fix on recipe format and conda itself.

number: 0

requirements:
host:
- python
- setuptools >=61.0
- pip
run:
- python

test:
imports:
- aifc
commands:
- pip check
requires:
- pip

about:
summary: Standard library aifc redistribution. "dead battery".
license: BSD-4-Clause
license_file: LICENSE
home: https://github.com/youknowone/python-deadlib

extra:
recipe-maintainers:
- bmcfee
42 changes: 42 additions & 0 deletions recipes/standard-chunk/meta.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
{% set name = "standard-chunk" %}
{% set version = "3.13.0" %}

package:
name: {{ name|lower }}
version: {{ version }}

source:
url: https://pypi.org/packages/source/{{ name[0] }}/{{ name }}/standard_chunk-{{ version }}.tar.gz
sha256: 4ac345d37d7e686d2755e01836b8d98eda0d1a3ee90375e597ae43aaf064d654

build:
noarch: python
script: {{ PYTHON }} -m pip install . -vv --no-deps --no-build-isolation
number: 0

requirements:
host:
- python {{ python_min }}
- setuptools >=75.0
- pip
run:
- python >={{ python_min }}

test:
imports:
- chunk
commands:
- pip check
requires:
- python {{ python_min }}
- pip

about:
summary: Standard library chunk redistribution. "dead battery".
license: BSD-4-Clause
license_file: LICENSE
home: https://github.com/youknowone/python-deadlib

extra:
recipe-maintainers:
- bmcfee
40 changes: 40 additions & 0 deletions recipes/standard-sunau/meta.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
{% set name = "standard-sunau" %}
{% set version = "3.13.0" %}

package:
name: {{ name|lower }}
version: {{ version }}

source:
url: https://pypi.org/packages/source/{{ name[0] }}/{{ name }}/standard_sunau-{{ version }}.tar.gz
sha256: b319a1ac95a09a2378a8442f403c66f4fd4b36616d6df6ae82b8e536ee790908

build:
script: {{ PYTHON }} -m pip install . -vv --no-deps --no-build-isolation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this one can be noarch too.

number: 0

requirements:
host:
- python
- setuptools >=75.0
- pip
run:
- python

test:
imports:
- sunau
commands:
- pip check
requires:
- pip

about:
summary: Standard library sunau redistribution. "dead battery".
license: BSD-4-Clause
license_file: LICENSE
home: https://github.com/youknowone/python-deadlib

extra:
recipe-maintainers:
- bmcfee