This is an inference based on a change in legal terms. No resolution yet if it reflects any deeper intent. (I suspect it's made by lawyers who default to 'make sure we control everything' when they write their terms, like every other corporate ToS we all supposedly agree to willingly.)
Still, I've seen that PyPI costs a lot to run, and just like ReadTheDocs I expect that a future PyPI will need a bigger income stream somehow.
I also well remember that PyPI mandated 2FA even for those who didn't want to switch, which is an ever-present reminder that they control distribution.
I stopped distributing on PyPI years ago, in favor of my own "simple index" package distribution.
I wish pip etc. had a good mechanism already for mitigating dependency confusion. I can see that people who download my package also try downloading other packages, like pybind11, from my index, even though it isn't even a dependency of mine.
The actual bandwidth is being fronted by Fastly. At commercial rates (of course it costs them less than that to provide) it would be a few times the entirety of PSF funding.
They have quite few staff and IIRC they aren't paid. But we'd be better off if both of those were fixed, I'm sure.
>I also well remember that PyPI mandated 2FA even for those who didn't want to switch
I got to learn my options for authenticator programs on my desktop as a result. Now I'm more upset that I can't use it for my bank.
>I stopped distributing on PyPI years ago, in favor of my own "simple index" package distribution.
Man, it's hard enough as is to promote FOSS code as an independent developer, how are you getting people to use your index?
>I wish pip etc. had a good mechanism already for mitigating dependency confusion.
They can't do anything about people not knowing which index has which package. A lockfile standard is coming to the ecosytem, at least (PEP 751), and some kind of namespacing (in the distribution names, not just "namespace packages" on import) is coming to PyPI. But abstract dependency specifications don't say anything about the index in pyproject.toml etc. How do other ecosystems approach this?
> I can see that people who download my package also try downloading other packages, like pybind11, from my index, even though it isn't even a dependency of mine.
Is this because you list them as abstract dependencies, or... ?
I switched from a FOSS license to a proprietary license, and charge for commercial users. The version on the index is for those who want to try it out.
It requires a license key to unlock the full set of features, which I provide to demo evals and to academics, generally under a 1 month or 1 year period.
> about people not knowing which index has which package.
I've read enough about the issues to know it's a tough nut to crack. What I mean is to say that only xyz should be downloaded from example.com/simple/ and anything else must be found by some other means.
> Is this because you list them as abstract dependencies, or... ?
I do not. I have two dependencies, no transitive dependencies, and no C++.
This is an inference based on a change in legal terms. No resolution yet if it reflects any deeper intent. (I suspect it's made by lawyers who default to 'make sure we control everything' when they write their terms, like every other corporate ToS we all supposedly agree to willingly.)
Still, I've seen that PyPI costs a lot to run, and just like ReadTheDocs I expect that a future PyPI will need a bigger income stream somehow.
I also well remember that PyPI mandated 2FA even for those who didn't want to switch, which is an ever-present reminder that they control distribution.
I stopped distributing on PyPI years ago, in favor of my own "simple index" package distribution.
I wish pip etc. had a good mechanism already for mitigating dependency confusion. I can see that people who download my package also try downloading other packages, like pybind11, from my index, even though it isn't even a dependency of mine.
> I've seen that PyPI costs a lot to run
The actual bandwidth is being fronted by Fastly. At commercial rates (of course it costs them less than that to provide) it would be a few times the entirety of PSF funding.
They have quite few staff and IIRC they aren't paid. But we'd be better off if both of those were fixed, I'm sure.
>I also well remember that PyPI mandated 2FA even for those who didn't want to switch
I got to learn my options for authenticator programs on my desktop as a result. Now I'm more upset that I can't use it for my bank.
>I stopped distributing on PyPI years ago, in favor of my own "simple index" package distribution.
Man, it's hard enough as is to promote FOSS code as an independent developer, how are you getting people to use your index?
>I wish pip etc. had a good mechanism already for mitigating dependency confusion.
They can't do anything about people not knowing which index has which package. A lockfile standard is coming to the ecosytem, at least (PEP 751), and some kind of namespacing (in the distribution names, not just "namespace packages" on import) is coming to PyPI. But abstract dependency specifications don't say anything about the index in pyproject.toml etc. How do other ecosystems approach this?
> I can see that people who download my package also try downloading other packages, like pybind11, from my index, even though it isn't even a dependency of mine.
Is this because you list them as abstract dependencies, or... ?
> how are you getting people to use your index?
I switched from a FOSS license to a proprietary license, and charge for commercial users. The version on the index is for those who want to try it out.
It requires a license key to unlock the full set of features, which I provide to demo evals and to academics, generally under a 1 month or 1 year period.
> about people not knowing which index has which package.
I've read enough about the issues to know it's a tough nut to crack. What I mean is to say that only xyz should be downloaded from example.com/simple/ and anything else must be found by some other means.
> Is this because you list them as abstract dependencies, or... ?
I do not. I have two dependencies, no transitive dependencies, and no C++.