Specify azure requirements in date version

[benjaminkaplan]

Azure publishes their packages with both date based versions and absolute versions. Currently, adlfs only specifies using the absolute version (eg. azure-core==1.28.0). This is an issue because Azure does not support some of their packages in this manner.

I created an issue with the Azure team, which they seem wholly uninterested in resolving. You can see it here

With that being the case, can we update the version requirements here to support the date based versioning system?

The biggest issue is azure-core >1.28.0 and <2.0.0. These versions are contained within packages 2023.09.01 to 2025.09.01 which can be seen here.

To be clear, it would be ideal to specify the requirements in both absolute form and date form, because some people still use the absolute form. But Azure has made it impossible to only use the absolute form, as some packages are simply only available in the date form (see the issue linked above).

However, I do not know if it is technically possible to list a parallel set of requirements in conda.

[kyleknap]

@benjaminkaplan can you provide a set of commands/steps to be able to reproduce the issue you are seeing and better illustrate your use case? Running the conda install -c conda-forge adlfs command from the quickstart in the readme was working fine for me. Is this an issue only when you are trying to use pinned dependency versions with conda?

[benjaminkaplan]

The issue arises if you want to use the latest version of adlfs and the latest version of anything from the microsoft conda repo. For this example I will use azure-communication, whose latest version is 2025.09.01

As an example, if you created an env with this command:
conda create -n myenv conda-forge::adlfs microsoft::azure-communication
You would end up with adlfs v2022.10.0. This is quite old and is missing many of the newer adlfs features

If you specify the versions like this:
conda create -n myenv conda-forge::adlfs-2025.8.0 microsoft::azure-communication=2025.09.01
then you will get this resolution error:

You can see from the error that azure-core is trying to be installed with 2 different versions (<2.0.0 and >=2025.09.01).
However, you can see here that 2025.09.01 actually includes 1.35.0.

By removing the restriction of <2.0.0 you would allow users to specify the versions in the "azure preferred" manor.

[kyleknap]

@benjaminkaplan Thanks for the context. It is interesting that the conda packages in the Microsoft channel seem to bundle multiple SDK packages as a single conda package and not offer them as individual standalone packages like they are in conda forge (e.g., here is azure-common). I suspect without hosting non-bundled versions there would not really be a path forward to having "absolute" versions because these packages encompass multiple packages each with different versions to choose from as the canonical absolute version. To make matters worse, the azure-core bundled conda package collides with the standalone azure-core PyPI/conda forge package. Would it instead be possible to rely on the Azure SDK packages in the conda forge channel instead?

@martindurant do you have thoughts on this? I'm hesitant on loosening the upper bound on azure-core in the pyproject.toml as that would protect adlfs if azure core ever major version bumped and broke adlfs functionality. Would loosening the upper bound just in the adlfs conda recipe something that makes sense? Do we make any guarantees in compatibility with packages outside of conda forge?

[martindurant]

Domes anyone have a contact with the packaging team for the MS conda channel? It would be good to understand their strategy/

[benjaminkaplan]

@kyleknap
You cannot rely solely on the conda-forge channel for azure packages. As I outlined in my issue here there are multiple packages that do not exist in conda-forge, but they are included as part of a date package in the microsoft channel.

For example:

1. azure-communication-email does not exist at all in conda-forge
2. azure-mgmt-network has an extremely old version (v23.0.0) in conda-forge, but the modern version is included in azure-mgmt (v30.0.0)

When I wrote my issue in the Azure SDK repo they posted a comment clearly indicating they did not read anything I wrote.
And they have utterly refused to fix anything.

[kyleknap]

@martindurant we can follow up with the Microsoft team that owns the channel. Mainly wanted to check with you first on expectations especially since I do not have much experience with the conda ecosystem.

@benjaminkaplan got it. I was thinking of the more widely used Azure SDK packages like azure-core and azure-storage-blob when I suggested to use conda forge instead, but I did not catch the gap for the packages that you called out.

I'll update this issue with what we learn.

[martindurant]

I would remark, that for the projects I directly manage, the conda-forge and pypi dependencies are always identical, and the only other conda channel of relevance to me (defaults) is also the same, although usually with a small lag.

It has been the trend for conda packages to include wider dependencies than their pypi counterparts, particularly making some/all of the optional extras required. The alternative path is to split out a -core and -all metapackage where the latter depends on the former plus extras.

The case where there are different and incompatible versioning schemes, I have not come across anywhere.

I agree with @kyleknap that unbounded dependencies within the SDK are dangerous, and I've been bitten by this myself before. I'm not sure if they can be specified to pull either/or from the two numbering systems. This all suggests that maybe the MS channel packagers ought to package adlfs too, and then they can decide how best it fits in with the rest of their channel.

[benjaminkaplan]

@kyleknap
Have you heard any update from the team that runs the microsoft conda channel?

@martindurant
I understand the desire to prevent unbounded versions, however this is already being done with azure-storage-blob. In order to resolve this, we either need to publish two parallel sets of version requirements, or remove the upper bound on version

[kyleknap]

@benjaminkaplan I don't have an update yet on my side.