generate-recipe pypi produces bad test imports

[pavelzw]

❯ rattler-build generate-recipe pypi pydiverse-common
Generating recipe for pydiverse-common
context:
  version: 0.1.0

package:
  name: pydiverse-common
  version: ${{ version }}

source:
- url: https://pypi.org/packages/source/p/pydiverse-common/pydiverse_common-${{ version }}.tar.gz
  sha256: 19208ce0d7646c2acf6db6c17e4947e61f4da306e928c3ddee3bbc9c2e2b4d19

build:
  script: ${{ PYTHON }} -m pip install .
  noarch: python

requirements:
  host:
  - python >=3.9
  - hatchling
  - pip
  run:
  - python >=3.9

tests:
- python:
    imports:
    - pydiverse-common <---- this should be pydiverse.common
    pip_check: true

about:
  summary: Common functionality shared between pydiverse libraries
...

[trim21]

maybe the default should be pydiverse_common, there are indeed in some case it's pydiverse.common, but pydiverse_common would fit more packages.

[pavelzw]

yes but definitely not pydiverse-common

[trim21]

it also missing --no-deps in pip install command?

[trim21]

This is just a question: why don't we install pkg-py3-none-any.whl to avoid the need of hatchling/setuptools/flit/poetry when it's a noarch:python package?

[pavelzw]

We want to properly build things from source Especially for compiled packages, we want to link against our own versions of OpenSSL,…

[trim21]

I mean noarch-python packages here, so no linkage is required...

[wolfv]

Yes, I agree that it could be nice to make a more straight-forward way of building packages from noarch wheels. You should be able to set a wheel as your source and then use pip install ...wheel-file.whl --no-deps.

If you want to document that, that could be nice.

[wolfv]

I think we could theoretically try to deduce the import name from the contents of the sdist file. But I am not sure whether it's straightforward & worth it.