> Yes, you literally can. Whatever you think is the problem with this, it's not a problem for me, or hundreds of people I've worked with, who are doing this.
Well, numbers of people who don't know how something work isn't a proof of anything... Also, "doesn't work" in this context means that the design of the feature is flawed and in corner cases cannot be made to work. This is different from, for example, a bug that suggest that the design is fine, but implementation failed. This is also different from "doesn't work at all". But, it would be too obviously false to be considered.
The reason why it doesn't work is this: some Python packages are distributed as source distributions. There are plenty of reasons for that, which I don't want to go into. In this case, pip will try to build these packages, unless you tell it not to (but then you won't be able to install them, which is probably not what you want). It doesn't matter whether you use pyproject.toml or any other description of the build system you use: pip will have to somehow find it and run it. And, at this point, all bets are off. conda may improve detection of such cases and identify potential breakage caused by this, but there isn't a universal solution to this problem, and with the current position from people working on Python infrastructure there won't be one.
Conda will be also unlikely to give it in to pip because conda's packages are a lot better designed than PyPI. It would be a huge downgrade if they do. So, I expect this to be a problem for a long time.
> Yeah, two things having an overlap in functionality does not mean there is some kind of competition.
This is exactly what it means: overlap in functionality means competition.
> yeah, it's a snake. haha, get it?
This took an unexpected turn to... an elementary school?
Yeah, I’m sorry, you’re bringing this down below elementary schools logic adequacy levels.
No, overlap in functionality is not the definition of competition. Mugs and cups have overlap in functionality, it doesn’t mean they’re competing in your cabinet. You can use either one, depending on the specific occasion or fancy.
You’ve rendered the following terms completely moot:
“Something works” and “something competes”
Arguing the sky is not blue because you can see infrared, which few people care about, is great entertainment, and I’m learning a lot about your vision, but you’re not going to enlighten anyone.
Well, numbers of people who don't know how something work isn't a proof of anything... Also, "doesn't work" in this context means that the design of the feature is flawed and in corner cases cannot be made to work. This is different from, for example, a bug that suggest that the design is fine, but implementation failed. This is also different from "doesn't work at all". But, it would be too obviously false to be considered.
The reason why it doesn't work is this: some Python packages are distributed as source distributions. There are plenty of reasons for that, which I don't want to go into. In this case, pip will try to build these packages, unless you tell it not to (but then you won't be able to install them, which is probably not what you want). It doesn't matter whether you use pyproject.toml or any other description of the build system you use: pip will have to somehow find it and run it. And, at this point, all bets are off. conda may improve detection of such cases and identify potential breakage caused by this, but there isn't a universal solution to this problem, and with the current position from people working on Python infrastructure there won't be one.
Conda will be also unlikely to give it in to pip because conda's packages are a lot better designed than PyPI. It would be a huge downgrade if they do. So, I expect this to be a problem for a long time.
> Yeah, two things having an overlap in functionality does not mean there is some kind of competition.
This is exactly what it means: overlap in functionality means competition.
> yeah, it's a snake. haha, get it?
This took an unexpected turn to... an elementary school?