OpenAI just acquired Astral who have an index service called pyx, so they would have a step up.
My understanding though is most corporations that take security seriously either build everything themselves in a sandbox, or use something like JFrog's Artifactory with various security checks, and don't let users directly connect to public indexes. So I'm not sure what the market is.
Some of these are uv following the standards while pip is still migrating away from legacy behavior, some of these are design choices that uv has made, because the standard is underdefined, it's a tool specific choice, or uv decided not to follow the standards for whatever reason.
If you're concerned about dependency confusion attacks you should host your own index and vet what goes on to it.
But there is a better solution coming, PEP 708 was developed for this and is in prototype on pypi.org, so it's an overstatement to say "don't even have a way to avoid dependency confusion attacks ".
It is, however, a non-trivial problem, and more solutions will likely come over the years, many Python packaging tools like uv and poetry (and likely others) have way to name indexes and pin specific packages to indexes, which appears to be a promising UX.
> I don’t know much about voting systems, but I know someone who does. Unfortunately he’s currently banned. Maybe we can wait until his 3-month ban expires and ask him for advice?
Currently, the text reads:
> This post was flagged by the community and is temporarily hidden.
Since it has been hidden for more than 24 hours, this suggests that a moderator action has marked it as permanently hidden. Due to a recent decision, this means no one outside of the moderators or admins can view it: https://discuss.python.org/t/moderated-posts-are-no-longer-p...
Edit 2: Some comments suggest that Guido was banned from posting, but this is not accurate. I have edited the title from "Guido van Rossum's Post Removed for Violating Python Community Guidelines" to "A Post by Guido van Rossum Removed for Violating Python Community Guidelines" to clarify what actually happened.
pip will not do that, it will attempt to use the latest version under the user requirements, only if there is a conflict between two packages will it backtrack on old versions of a package, uv does exactly the same.
Further, if a package index supports PEP 658 metadata, pip will use that to resolve and not download the entire wheel.
uv does the same but adds extra optimizations, both clever ones that pip should probably adopt, and ones which involve assumptions that don't strictly comply to the standards, which pip should probably not adopt.
I would say, as someone who works on performance of pip, no one else was able to reproduce OPs severe performance issue, not saying it didn't happen, just it was an edge case on specific hardware (I am assuming it was this issue https://github.com/pypa/pip/issues/12314).
Since it was posted a lot of work was done on areas which likely caused performance problems, and I would expect in the latest version of pip to see at least a doubling in performance, e.g. I created a scenario similar to OPs that dropped from 266 seconds to 48 seconds on my machine, and more improvements have been made since then. However OP has never followed up to let us know if it improved.
Now, that's not to say you shouldn't use uv, it's performance is great. But just a lot of volunteer work has been put in over the last year (well before uv was announced) to improve the default Python package install performance. And one last thing:
> for a non-compiler language?
Installing packages from PyPI can involve compiling C, C++, Rust, etc. Python's packaging is very very flexible, and in lots of cases it can take a lot of time.
Maybe it’s the fact it can be done with multiple operators and strong encryption that is hard to grok, but at least here is a very simple example of a limited partially homomorphic encryption:
You have a 7-bit character representation (e.g. ASCII) and your encryption is to add 1 mod 128. E.g. 0 -> 1, 1 -> 2, ... 126 -> 127, 127 -> 0.
As it turns out, all your operations can be represented as adding or subtracting constants. You can now encrypt your data (+1), send it to a remote server, send all the adding and subtracting operations, pull back the processed data, decrypt the data (-1).
Of course, this example is neither useful encryption nor generally useful operation, but can be useful for grokking why it might be possible.
> The people who say "just use pip and venv" don't understand the issue.
The people saying that say that because it works for them and it solved their problems.
> setuptools is somewhat deprecated but not really
setuptools remains the default and most popular backend (the thing that builds your package). What was deprecated was calling it directly, instead you use pip or build or any other frontend.
Why? One reason is because it exposed lots of non-standard eccentricities that users would then start to rely on, breaking the effort of standardisation.
> Or perhaps pyproject.toml? If the latter, flit, poetry and the 100 other frontends all have a different syntax.
They all use toml syntax, they all use the same build dependency standard, poetry does not use PEP 440 configuring version dependencies, but it does read PEP 440 dependencies from wheel metadata fine. I hope one day the version dependency spec can be updated with everything that has been learnt, from both Poetry and the rest of the ecosystem, but Python packaging is a slow moving beast.
> Should you use pip? Well, the latest hotness are the search-unfriendly named modules "build" and "install", which create a completely isolated environment.
pip does this for you though, I'm not sure why most end users need to know "build" or "install" exist.
> Which is the officially supported tool that will stay supported and not ripped out like distutils?
I'm not sure why you think any of these are "the officially supported tool", they are an attempt by various PyPA members to minimally and correctly implement the standards, but PyPA is a loose collection of volunteers.
Whereas, CPython core dev have a pretty clear arms length attitude towards all of packaging. This for me feels like the real contention in the Python packaging world.
> Questions over questions. And all that for creating a simple zip archive of a directory, which for some reason demands gigantic frameworks.
Well the people using pip and venv didn't have any of these questions, they just got on with it because it solved everything for them.
Likely you want your package to figure something out as it’s being built, or have interesting metadata, or include binaries, or something else not on the happy path, and you want your build tool to "just work" even though chances are you’re doing something not that simple or what the tool creator thought. Otherwise, if you really just need a “simple zip archive of a directory” just write out the directory and call python -m zipfile.
There’s nothing wrong with lots of people needing specific use cases, but it does mean all these build tools need to add lots and lots of options to accommodate them all, and before you know it you're complaining of a "gigantic framework" (even though I wouldn't describe either setuptools or hatchling like that).
I'm the one arguing against this move, I've already made my thoughts clear that it's a lot of churn, e.g. the PR to remove it from Pip literally caused Pip to have to do a bug release, and has valid use cases, e.g. modelling datetime data types from spreadsheets and databases that do not have timezones.
But I also accept I'm not the one maintaining Python, so I've updated my codebase appropriately (`datetime.datetime.now(datetime.UTC).replace(tzinfo=None)`). Python is not a backwards compatability language, and it's clearly not a strong motivation for most users as I don't see anyone attempting to write a backwards compatibility shim over the standard library, so no point complaining too much.
If there is a contradiction between the Language Reference and CPython then one, or both, of them needs to be updated and it's treated on a case by case basis.
If an alternative Python implementation follows the Language Reference but chooses different details outside it, that doesn't stop it from being "Python". Of course practically speaking most alternative implementations are incentivized to closely follow CPython.
The main difference now is there is an actual standard rather than a de facto tool that becomes the standard.
The idea is that different tools may rise and fall in popularity but they should all be following the standard so the compatability breaks should be minimal.
Will it work? No idea, but it's the best attempt to make things work well for everyone yet.
Python 3.12 might be the biggest churn moment, but there are probably a few more down the road, such as dropping legacy version specifiers.
It's over 1200 lines of code, it's not like it's 100 lines of code and can fit on a single screen
> Globals are fine--they're even marked as such
I would argue that globals in this context are not fine from a code maintainability point of view.
By using globals here it's hard to know from a function call if it's going to mutate global state or not. If all the functions were methods of the same class instance, and other functions were just functions or part of some other class, then it gives you a clear grouping of calls which are related to mutating that state.
In general I would argue if you are ever in the situation of "I have more than two or three functions that are related to each other and they all need to mutate the same state so I use a mutable global" or "I pass around the mutable state via arguments" then make a class! It creates an obvious semantic grouping of callables.
> I don't think globals are so awful for certain things. I prefer a more functional approach where you have simple composable standalone functions instead of classes. Obviously classes have a role, but I find they sometimes overly complicate things and make the logic harder to follow and debug.
But "globals" and "composable standalone functions" are contradictory, if you're mutating global state your function is neither composable nor standalone.
What you've got is a poor mans class instance using global instead of self.
Quickly skimming some points that would irratate me if I had to maintain this script:
* Importing Paramiko but regularly call `ssh` via subprocess
* Unused functions like `execute_network_commands_func`
* Sharing state via a global instead of creating a class
Overall it's fit for purpose, but makes a lot of assumptions about the host and client machines. As you said in the thread you're running a very small number of servers (less than 30). I've written similiar things over the years and they are great for what you need.
When I heavily used Splunk (back in 2013) I was in an application production support team that managed over 100 productions servers for over a dozen applications, there were dozens of other teams in similar situations across the company. The Splunk instance was managed by a central team, minimal assumptions about the client environment, had well defined permissions, understood common and essoteric logging formats, and could reinterpret the log structure at query time. A script like this is not competiting in that kind of situation.
My understanding though is most corporations that take security seriously either build everything themselves in a sandbox, or use something like JFrog's Artifactory with various security checks, and don't let users directly connect to public indexes. So I'm not sure what the market is.