You have Anaconda packaging world vs PyPI. You have pyproject.toml for project management, which is not supported by Anaconda or the flagship documentation generation tool: Sphynx. You have half a dozen of package installers, none of them work to the full extent / all have different problems. You have plenty of ways to install Python, all of them suck. You have plenty of ways to do some common tasks, s.a. GUI, Web, automation: and all of them suck in different ways, w/o a hint of unifying link. Similarly, you have an, allegedly, common relational database interface, but most commonly used SQL bindings don't use it. And the list goes on.
As I said, it's only because .so extensions were hard. If every package were pure Python, I would simply copy paste them in my source code `lib` path.
Don't laugh at me, this is called "vendoring" or "static linking" by other languages, and the "requests" famously included a version of urllib3 for quite a while
Oh, but there's plenty more to Python packaging... unfortunately. You can put a ton of random stuff that's not Python modules into wheels: scripts, data, headers. Anaconda doesn't support most of that.
There is no fracture or "versus" here. You can pip install on top of Anaconda. Anaconda provides a more stringent solver and OS level packages that some pip level modules often depend on, it just solves the integration problem, but I use both, including requirements.txt in my Anaconda env.yml all the time.
> You have pyproject.toml for project management, which is not supported by Anaconda or the flagship documentation generation tool: Sphynx.
Again, Anaconda is not "standard" python thing, it is a replacement for build OS level packages, such as GDAL, which is a just a subset of Python modules. Anaconda does not need to support standard python tooling, because those python tools exist outside of Anaconda.
To simplify, for every Anaconda package, you can likely find it in PyPI, but for every PyPI, you will not find it in for conda. Anaconda is not a competitor for PyPI, it does not need to replicate every PyPI feature.
> You have plenty of ways to install Python, all of them suck.
What does this actually mean? You install Python with all the major OS installation methods, and absolutely none of them suck, any more than installing anything on this OS does. The standard ways are Python Setup.exe, apt-get install, and brew install. Yes, you can additional options such as conda distros, yet what exactly sucks about them? Nothing.
> You have plenty of ways to do some common tasks, s.a. GUI, Web, automation: and all of them suck in different ways, w/o a hint of unifying link.
I think I'm starting to get it. Everything sucks if you've been around long enough. Django is vastly prevalent web framework. wx widgets is standard, and there are bindings for most GUI toolkits. There are many toolkits, is it Pythons fault they all got invented by different organizations? Is it an interpreted language responsiblity to provide a cross platform GUI toolkit for you?
> Similarly, you have an, allegedly, common relational database interface, but most commonly used SQL bindings don't use it.
What are you even talking about? Who in the world cares about this? People use database specific libraries, in every single language, because every database has its own set of features.
> And the list goes on.
Your list reeks of someone flinging critiques without even knowing what they’re talking about—just a lot of hot air fueled by emotional baggage, likely from some long-dead language you once cherished before it was mercifully abandoned.
This is what people believe when they don't know how it works: no, you cannot. But this isn't even the point. The point is that you have different tools that have no interop between them, nothing in common at all: conda-build and setuptools (and there's plenty of half-implemented Python packaging tools that cannot package native extensions).
> Again, Anaconda is not "standard" python thing
Python doesn't have a standard at all. Nothing is standard about any aspect of Python outside of marginal stuff like floating point or XML etc. Anaconda is as legitimate as any other tool that works with Python. This is how it was intended. You probably wanted to say "not as popular as", which would be true, but also Anaconda is popular enough for this to be a problem.
> which is a just a subset of Python modules.
Are you sure you know what Anaconda is? You make the opposite impression...
> Anaconda is not a competitor for PyPI
Anaconda is a competitor of PyPI. It literally provides its own package index (this is what P and I stand for in PyPI).
> Everything sucks if you've been around long enough.
Python sucks. Let's not extrapolate this to other things. Marriages, for example, usually don't suck if they lasted long enough. I can think about few more things that get better with time.
But, Python is not a good language by any metric. But it's also not unique in that aspect. So, idk why would you drive so much attention to this fact. Good languages are rare, good and popular -- I'm yet to find one.
> Who in the world cares about this?
Parent poster of the post you replied to. But, more broadly, common interfaces are important because they allow one to avoid vendor lock-in, lower maintenance cost, reduce the onboarding time for the new developers.
> Your list reeks of someone flinging critiques without even knowing what they’re talking about
I don't care to name names. Python is garbage, and I never claimed otherwise. As for knowing my stuff... so far you seem to be that kind of guy. But, keep going. Sometimes the urge to argue may lead to you read about the subject of your argument.
> This is what people believe when they don't know how it works: no, you cannot.
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. So, your problem is a niche nitpic irrelevant to pretty much anyone.
> Python doesn't have a standard at all.
Again, no one cares, in a practical sense. When you install Python 3, you get pip, that's what "standard" means here, colloqually. You calling something "garbage" because of your desire for some kind of strict hierarchy of paperwork is your, very niche, personal problem that no one else cares about.
> Are you sure you know what Anaconda is? You make the opposite impression...
yeah, it's a snake. haha, get it?
> Anaconda is a competitor of PyPI. It literally provides its own package index (this is what P and I stand for in PyPI).
Yeah, two things having an overlap in functionality does not mean there is some kind of competition. It's just different tools solving similar, but different problems.
> Let's not extrapolate this to other things. Marriages, for example, usually don't suck if they lasted long enough. I can think about few more things that get better with time.
No, actually, the entire point of the saying went over your head. If something has been around long enough, it has accumulated both good and bad. Marriages, any things you can think of. The point is that you judge the whole thing, not just by how bad the bad thing is. Python is solving a huge amount of technical problems, and for many of those problems, it sucks a lot less than PHP, Perl, C. The sheer fact that it is popular makes it suck less than any language that is obscure, that no one else know, except you. I'm sorry you have a favorite BNF grammar that is useless for getting actual things done in the real world.
> I don't care to name names. Python is garbage, and I never claimed otherwise. As for knowing my stuff... so far you seem to be that kind of guy. But, keep going. Sometimes the urge to argue may lead to you read about the subject of your argument.
What you think you know, by merelly calling Python hot garbage, you lose any intellectual authority, by displaying emotional immaturity. Why not throw some names around? I can name Oberon, it's a better language. There are better designed languages. It's all the rest of the rant, that is complete nonsense, that shows someone who clearly doesn't understand why people use Python to do things like find new particles, earth like planets, or cancer curing molecules, let alone build boring web apps. Anaconda works great, pip works great, Python is great to read and write, the library ecosystem is fantastic, it's the best language to get a lot of work done, and I've considered all other choices every other project for 20 some years, and Python has been many times the top choice.
> Sometimes the urge to argue may lead to you read about the subject of your argument.
This is not an argument, you're fighting windmills, and I'm playing the internet, lol.
> 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.
