requests is an optional dependency but there's no try/except guard

[jaimergp]

Checklist

• I added a descriptive title
• I searched open reports and couldn't find a duplicate

What happened?

If a user tries to use the remote features from conda_package_streaming.url with a regular conda create -n cps conda-package-streaming, they will run into an ImportError for requests because the dependency was removed from the recipe.

I would ask to either:

• Reconsider the optional requests dependency. I don't think it's thaaat big?
• Create a new output conda-package-streaming-core + conda-package-streaming without and with requests, respectively.
• Add a try / except ImportError clause similar to how zstandard is handled.

Conda Info

N/A

Conda Config

N/A

Conda list

N/A

Additional Context

Seen in conda/conda-package-handling#254

[dholth]

I would be inclined to go in the other direction; requests does have a real dependency tree and it is unfortunate that we should require it for basic packing/unpacking of .conda packages.

If we had a try/except for conda_package_streaming.url, what would it do? The url module can't work at all without requests?

[jezdez]

I wonder, given the relation between conda-package-handling and conda-package-streaming, if a merging of conda-package-streaming into conda-package-handling would be preferable.

[dholth]

I see conda-package-streaming as providing a "new", composable API and conda-package-handling existing only for backwards compatibility and the cph CLI. -streaming also replaces libarchive from pre-2.0 conda-package-handling. I would not merge the projects.