Support generic python package with pinned OS

[analog-cbarber]

This should apply the appropriate OS keys to the environment markers
in dependencies.

[jjhelmus]

I'd particularly interested in the feature and can work on this.

Would using the environment markers from the running interpreter while providing an option to override the markers be a reasonable path forward? This would create a conda package that could be immediately installed into the environment that created it.

A few other items that should be considered when making generic python packages:

• The site-packages directory will be platform dependent and may include the Python version, e.g. lib/python3.11/site-packages.
• Console script should to be created. This can be done by reading the console_script section of the entry_points.txt file in the wheel's .dist-info directory and applying these to a script template.
• The conda package should contain compiled byte-code (.pyc) files. py_compile in the standard library can create these but is not cross-platform or cross-interpreter. One option for these cases would be to create empty byte-code files with an old timestamp so that conda removes them but the interpreter updates them when the the module is loaded.
• The RECORDS file in the .dist-info directory should include these newly created files.
• .data directories, Support wheel .data directory #91, in wheels can be moved to their proper location.

[analog-cbarber]

I think using the current interpreter's markers makes sense as a default, but we would definitely want to support command line arguments to build package for other platforms.

You should take a look at the conda install implementation to understand what it does for python packages. For python noarch packages at least it will move the site-packages directory to the appropriate place at install time. My thought was that we could basically generate a python noarch package but with the platform metadata pinned and encoded in the file name for disambiguation.

This issue is specifically for the case of a pinned OS but NOT a pinned python, so it would not be appropriate to ihclude byte compiled files. And I also don't want to generate packages that contain multiple site packages either. We just want to take advantage of the python support already inherent in conda install.