Python-specific noarch packages

[jbednar]

I work almost entirely with pure Python packages with the same codebase for both Python2 and Python3 (param, imagen, holoviews), and thus I should be able to build noarch conda packages and not have to worry about different platforms. However, in some cases we need to build packages that specify different dependencies on Python2 compared to Python3. As far as we can tell, specifying the Python version for the package also means specifying the OS. Is there a way to build a package that is tied to a Python major version without being tied to a particular OS? If not, can that capability be added?

[joelhullcio]

I would like to also request the ability to build a noarch conda package that is python version specific but not platform (OS) specific. At JPM we need to build python2.7 packages that can run on linux-64 and windows-64 but we only have a linux box to build on. The packages we import in the code are available on both platforms and we develop and test on windows and test and deploy on linux so we know the code is compatible on both platforms so it would be better to only have to build one copy of each package for deployment. However, we want to restrict the conda packages to only install on python27 environments.

May I suggest adding a new parameter to conda recipes called just "noarch" that allows the python version to be specified but is platform agnostic.

[msarahan]

I'm not sure how cross-platform bytecode is, but I'll look into this soon.

[nicoddemus]

noarch packages are already supported, I believe this can be closed?

[mcg1969]

Ping. I'd like us to consider this again. We're hitting issues here with a customer, where a package is Python 3 only, but we're unable to specify that and have a noarch package. So this is not a matter of having a matrix of noarch packages, but simply being able to restrict the python versions that are compatible with a single package.

That said, it's not clear that why we couldn't support multiple python-version-specific builds of a noarch package.

[msarahan]

You can put constraints on python in the run section, and have it still be valid noarch. You won't get nice filename strings like you do with wheels, but the functionality is there.

[mcg1969]

Ah, that's great to know, thanks!

[mcg1969]

Does this mean we could conceivably build separate Python2 and Python3 noarch packages using the --python= kwargs? Or does that kwarg attempt to modify the build section as well? Perhaps we can modify that behavior so that, for noarch packages, only the run section is versioned.

[github-actions]

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

1. Verify that you can still reproduce the issue at hand
2. Comment that the issue is still reproducible and include:
   - What OS and version you reproduced the issue on
   - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!

[jbednar]

@msarahan 's comment makes it clear we can put constraints on the Python version, but there's not been a reply to @mcg1969 's question about whether we can easily build multiple packages for each Python version, or to my question about how to specify different dependencies depending on the Python version. Of course, Python 2 (my original reason for the request) no longer matters, but I think this would still come up for different Python 3 versions, particularly for functionality that's been added in a later Python 3 release but would need to be a separate download for earlier releases.

[mcg1969]

Actually separate builds for different Python versions is doable. I've learned a fair amount since I commented that :-)

The noarch pattern is actually much more flexible than I first conceived, especially coupled with variants and virtual meta packages.