Lifting Python packages across PyPI and Conda

I’m lifting pypi/hypothesis, which is lovely.

conda/hypothesis is the same library, but has no income available yet. It’s also distributed by downstream packagers, not the development team, which raises a few questions - they can’t give any of the security, maintainence, or license committments. On the other hand I can’t promise quick updates for bugs or security issues because I don’t control distribution (it’s usually a few days-to-weeks behind).

So how should this work? For me, it would be ideal if the usage from conda was added to that from PyPI, I lift both, and conda-users get notified that updates might be delayed relative to PyPI.

Hey @Zac-HD!

We’re not exactly sure how to handle this right now. We’re still evaluating it, so we don’t rush an incorrect solution.

We’re currently viewing it as analogous to a Linux distribution. When the Anaconda company repackages PyPI stuff to Conda, they are providing similar assurances to their customers that we are providing to Tidelift subscribers for the community registries.

If Anaconda is doing this work, and you don’t have access to push your updates to their distribution mechanisms, it hard to provide the assurances Tidelift affords our subscribers.

Do you have any thoughts on how this might work better? We’d love some to hear anyone’s thoughts around this to help us move to a more concrete answer.

Cheers,
-Blaine

When the Anaconda company repackages PyPI stuff to Conda, they are providing similar assurances to their customers that we are providing to Tidelift subscribers for the community registries.

If this was actually the case I’d feel quite differently about it! Unfortunately they can’t provide license indemnification at all, and it’s not feasible to provide bugfixes or security patches (so they don’t).

So far as I can tell it’s just a convenience to make conda install hypothesis work, at cost of usually giving an outdated version contrary to our packaging guidelines.

Conda also has a concept of channels, so conda install -c conda-forge hypothesis is published by a different team than conda install [-c main] hypothesis , with different update cycles. I don’t know if Tidelift can handle this at all!

Do you have any thoughts on how this might work better? We’d love some to hear anyone’s thoughts around this to help us move to a more concrete answer.

I think the best model is that “conda/hypothesis” depends on “pypi/hypothesis” - upstream should be able to lift whatever they contribute (in this case some extra release automation), but usage-via-conda should count towards total-usage-via-pypi.

Hi Zac. This is not quite correct. Anaconda the company provides services and contracts for these things to its customers. That’s why it often takes longer for package updates to appear in the “defaults” channel.

I’m afraid those packaging guidelines are very hard to follow for any redistributor. Since hypothesis may be a dependency of other packages, and also because companies often want to pull from a curated repository, I don’t think it’s reasonable to expect Anaconda to either commit to prioritizing hypothesis updates over other packages or to stop redistributing it completely.

Conda-forge (conda-forge.org/) is a community-driven packaging effort. Any package author like you is very welcome and encouraged to maintain their own package, and the conda-forge team listens to feedback from package authors.

Note that conda-forge has bots that automatically open PRs for any update published to PyPI. For a pure Python package like hypothesis it’s a matter of merging that PR (which you can get the rights for if you want) to be up-to-date in hours/days.

For “conda-forge/hypothesis” I think that’s a nice suggestion.

And for the record: I’m not an Anaconda employee or conda-forge team member. I do maintain packages on both PyPI and conda-forge.