pyenv and uv let you install and switch between multiple Python versions.
As for uv, those come from the Python build standalone project, if I remember correctly, pyenv also installs from there, but don't quote me on that.
pyenv and uv let you install and switch between multiple Python versions.
As for uv, those come from the Python build standalone project, if I remember correctly, pyenv also installs from there, but don't quote me on that.
I moved all our projects (and devs) from poetry to uv. Reasons were poetry's non standard pyproject.toml syntax and speed, plus some weird quirks, e. g. if poetry asks for input and is not run with the verbose flag, devs often don't notice and believe it is stuck (even though it's in the default project README).
Personally, I update uv on my local machine as soon as a new release is available so I can track any breaking changes. Couple of months in, I can say there were some hiccups in the beginning, but currently, it's smooth sailing, and the speed gain really affects productivity as well, mostly due to being able to not break away from a mental "flow" state while staring at updates, becoming suspicious something might be wrong. Don't get me wrong, apart from the custom syntax (poetry partially predates the pyproject PEP), poetry worked great for us for years, but uv feels nicer.
Recently, "uv build" was introduced, which simplified things. I wish there was an command to update the lock file while also updating the dependency specs in the project file. I ran some command today and by accident discovered that custom dependency groups (apart from e. g. "dev") have made it to uv, too.
"uv pip" does some things differently, in particular when resolving packages (it's possible to switch to pip's behavior now), but I do agree with the decisions, in particular the changes to prevent "dependency confusion" attacks.
As for the original question: Python really has a bit of a history of project management and build tools, I do feel however that the community and maintainers are finally getting somewhere.
cargo is a bit of an "unfair" comparison since its development happened much more aligned with Rust and its whole ecosystem and not as an afterthought by third party developers, but I agree: cargo is definitely a great benchmark how project and dependency management plus building should look like, along with rustup, it really makes the developer experience quite pleasant.
The need for virtual environments exists so that different projects can use different versions of dependencies and those dependencies can be installed in a project specific location vs a global, system location. Since Python is interpreted, these dependencies need to stick around for the lifetime of the program so they can be imported at runtime. poetry managed those in a separate folder in e. g. the user's cache directory, whereas uv for example stores the virtual environment in the project folder, which I strongly prefer.
cargo will download the matching dependencies (along with doing some caching) and link the correct version to the project, so a conceptual virtual environment doesn't need to exist for Rust. By default, rust links everything apart from the C runtime statically, so the dependencies are no longer neesed after the build - except you probably want to rebuild the project later, so there is some caching.
Finally, I'd also recommend to go and try setting up a project using astral's uv. It handles sane pyproject.toml files, will create/initialize new projects from a template, manages virtual environments and has CLI to build e. g. wheels or source distribution (you will need to specify which build backend to use. I use hatchling), but thats just a decision you make and express as one line in the project file. Note: hatchling is the build backend, hatch is pypa's project management, pretty much an alternative to poetry or uv.
uv will also install complete Python distributions (e. g. Python 3.12) if you need a different interpreter version for compatibility reasons
If you use workspaces in cargo, uv also does those.
uv init, uv add, uv lock --upgrade, uv sync, uv build and how uv handles tools you might want to install and run should really go a long way and probably provide an experience somewhat similar to cargo.
Didn't I just say that in the comment you replied to?
Also, ultraprocessed food is a fixed term that refers to
[...] foods [...] ready-to-eat or ready-to-heat industrial formulations made mainly with ingredients refined or extracted from foods and contain additives but little to no whole foods.
It's used as such in studies and reports.
Jaguars actually eat the leaves of b. capii, which acts as a MAOI in the Ayahuasca brew.
While there is some discussion that the harmala alkaloids in b. capii might also be slightly psychoactive in high doses, the actual main compound in Ayahuasca is DMT, which is certainly very psychoactive, but not bioavailable when consumed orally without a MAOI. Unless the jaguars have figured out how to combine the two and/or brew ayahuasca, I strongly doubt that's their intention and that they'd get comparable effects.
I think the idea stems from the BBC show Weird Nature showing a jaguar eating yage leaves in episode 6, "Peculiar Potions".
I'm not really sold on how well that content was researched.
Just in case you're not in on the joke:
You mean the company that had a feature in place that allowed law enforcement to request and access video footage from your devices without obtaining a warrant first?
As expected, their security measures were also found to be lacking.
Yeah, no thanks.
They actually joke about it in the show, screaming "Aah, a crocodile", and it's just some woman working there. Same with the director being a lion, I believe.
The exhibit has turtles and penguins.
I'm a big fan of archive.org and I regularly look for manuals, but they don't show up in common searches as a source, so knowing that now is really helpful. Thanks!
Some context:
After Elmo's venture into posting anime stuff on Twitter, this feels rather tame I guess. Or I'm just too jaded to care about this timeline any longer.
As someone who often lifts a finger, types out the first two sentences of a comment and then just resigns: thanks for the well-written comment.
I believe it doesn't really matter much whether you want to protect the environment from vibrations of the machine vs. protecting the machine from vibrations of the environment - in both cases, decoupling the systems is what you want to achieve.
Eventually, you want to build a TMD: https://en.m.wikipedia.org/wiki/Tuned_mass_damper
I personally had to deal with the case of a large format CNC machine transferring stepper motor vibrations into an adjacent office via the wall-mounted brackets it was sitting on. People started to complain shortly after installation since the noise was very audible in the otherwise quiet working environment.
The solution involved placing the machine on a plate mounted via rubber decouplers (see https://www.dayco.com/en/product/decouplers) which in turn was mounted to a shop-built TMD using a rubber core sandwiched between two foam plates. The rubber core works as both mass and absorbs additional vibrations. It was built following a paper, but unfortunately, that was around 7 years ago and I'm not sure I'll be able to dig the publication out again.
You can in fact simulate the TMD and do the tuning (see for example https://www.mathworks.com/help/simscape/ug/mass-spring-damper-in-simulink-and-simscape.html , though dedicated software packages also exist) but in all honesty, that will probably be overkill for your case.
Having your NAS sit on a 1/2" board of baltic birch plywood resting on a foam sandwich is probably going to do the trick in your case. You can easily create such a sandwich using foam, a rubber mat and some spray glue. Different foam densities will give different results and yield different "tunings" - you may have to play around with this a bit. I could imagine you'll most likely even be able to skip the second decoupling step (rubber feet/decouplers), in the aforementioned case the second decoupling allowed for another set of frequencies to be dampened (via a different overall rubber hardness) but also brought overall amplitude down.
Don't use super soft foam, as this will yield a wobbly base, something you probably want to avoid for your NAS. Also, make sure not to attach the base board to anything else apart from the foam, or you'll transmit vibrations again. If you don't like the appearance of the foam, you can build a small fence around it that goes up to the top of the base plate.
All that being said, there are also ready-made solutions like speaker dampening feet available: https://www.amazon.com/Tertullus-Speaker-Isolation-Feet-Anti-Vibration/dp/B09QC2L7N3
Most of them are made to decouple subwoofers, so they might fit into the frequency spectrum you specified. Those couls certainly be an affordable and rather quick way to solve the problem.
I did that on purpose, i. e. I wanted to confirm your thoughts about uv, drifted off into a general rant, remembered OP's original question and later realized it would have been better framed as a top level comment. In my defense, I was in an altered state of mind at the time.