> It's been explained many times before why this is not possible: the library doesn't actually have a version number.
Not possible? Come on.
Almost everyone already uses one of a small handfull of conventional ways to specify it, eg `__version__` attribute. It's long overdue that this be standardized so library versions can reliably be introspected at runtime.
Allowing multiple versions to be installed side-by-side and imported explicitly would be a massive improvement.
I believe the charitable interpretation is that it is not possible without breaking an enormous amount of legacy code. Which does feel close enough to “not possible”.
Some situations could be improved by allowing multiple library versions, but this would introduce new headaches elsewhere. I certainly do not want my program to have N copies of numpy, PyTorch, etc because some intermediate library claims to have just-so dependency tree.
What do you do today to resolve a dependency conflict when an intermediate library has a just-so dependency tree?
The charitable interpretation of this proposed feature is that it would handle this case exactly as well as the current situation, if the situation isn't improved by the feature.
This feature says nothing about the automatic installation of libraries.
This feature is absolutely not about supporting multiple simultaneous versions of a library at runtime.
In the situation you describe, there would have to be a dependency resolution, just like there is when installing the deps for a program today. It would be good enough for me if "first import wins".
> What do you do today to resolve a dependency conflict when an intermediate library has a just-so dependency tree?
When an installer resolves dependency conflicts, the project code isn't running. The installer is free to discover new constraints on the fly, and to backtrack. It is in effect all being done "statically", in the sense of being ahead of the time that any other system cares about it being complete and correct.
Python `import` statements on the other hand execute during the program's runtime, at arbitrary separation, with other code intervening.
> This feature says nothing about the automatic installation of libraries.
It doesn't have to. The runtime problems still occur.
I guess I'll have to reproduce the basic problem description from memory again. If you have modules A and B in your project that require conflicting versions of C, you need a way to load both at runtime. But the standard import mechanism already hard-codes the assumptions that i) imports are cached in a key-value store; ii) the values are singleton and client code absolutely may rely on this for correctness; iii) "C" is enough information for lookup. And the ecosystem is further built around the assumption that iv) this system is documented and stable and can be interacted with in many clever ways for metaprogramming. Changing any of this would be incredibly disruptive.
> This feature is absolutely not about supporting multiple simultaneous versions of a library at runtime.
> and support having multiple simultaneous versions of any Python library installed.
Which would really be the only reason for the feature. For the cases where a single version of the third-party code satisfies the entire codebase, the existing packaging mechanisms all work fine. (Plus they properly distinguish between import names and distribution names.)
> and support having multiple simultaneous versions of any Python library installed.
Installed. Not loaded.
The reason is to do away with virtual environments.
I just want to say `import [email protected] as np` in my code. If 2.3.2 is installed, it gets loaded as the singleton runtime library. If it's not installed, load the closest numpy available and print a warning to stderr. If a transient dependency in the runtime tree wants an incompatible numpy, tough luck, the best you get is a warning message on stderr.
You already have the A, B, C dependency resolution problem you describe today. And if it's not caught at the time of installing your dependencies, you see the failure at runtime.
You'd have to invent a different way, within existing Python syntax, to communicate the version, but you can do this today with sys.path and sys.meta_path hacks.
But virtual environments are quite simply not a big deal. Installed libraries can be hard-linked and maybe even symlinked between environments and this can be set up very quickly. A virtual environment is defined by the pyvenv.cfg marker file; you don't need to use or even have activation scripts, and you especially don't (generally) need a separate copy of pip for each one, even if you do use pip.
On the flip side, allowing multiple versions of a library in a virtual environment has very little effect on package resolution; it just allows success in cases of conflict, but normally there aren't conflicts (because you're typically making a separate environment for a single "root" package, and it's supposed to be possible to use that package in Python as it actually exists, without hacks). The installer still has to scrounge up metadata (and discover it recursively) and check constraints.
I've not experienced corruption like the author, since my workflow involves copying the raw files from sdcard to harddrive, and then importing into Photos. After processing the raws in Photos, I export a .jpg back out to the filesystem.
That's because my worry is corruption of the entire Library, which Photos stores as one gigantic opaque file/directory abomination. My .photoslibrary file is currently 70gb in size, and I'm terrified of what would happen if it becomes corrupted. The Photos app crashes not infrequently.
> That's because my worry is corruption of the entire Library, which Photos stores as one gigantic opaque file/directory abomination. My .photoslibrary file is currently 70gb in size, and I'm terrified of what would happen if it becomes corrupted.
It's a folder that acts like a file.
Right click > Show Package Contents works, and there's an "originals" folder that should have all your photos in normal everyday files.
Instead of being organized by album, they're all thrown together with the filenames as UUIDs instead of the original name, or any useful name whatsoever. The editing steps I've applied to the raw files are, of course, not present. The important parts are all stuffed into a single giant .sqlite file, it looks like there may be other shared resources as well.
The point is that - from a data safety standpoint - it would be better if all of the internal metadata were persisted per album, if not per photo. That way one corrupted file would only affect a small subset, rather than causing me to lose the whole library.
I hate to tell you to RTFM, but the QGIS team has put a lot of effort into the User Guide and very practical Training Manual.
If you're already familiar with typical GIS workflows, you'll breeze through them, and they'll help you wrap your head around the QGIS way of doing things.
The point is that potatoes are one of the top 4 food sources worldwide, and they collectively dwarf the percentages of the long tail of other food sources.
Proportions vary significantly continent-to-continent and culture-to-culture, such that it'd be more meaningless to try and put a more precise (but less accurate) number on it.
This is not difficult to parse out of the sentence if you choose to take a charitable rather than a pedantic perspective, which I recommend to you generally.
Not only does this sound excellent, with three great TB-303 synth engines with a colored delay, but it's very musical. The three patterns are locked to a common scale/mode, they autogenerate with compatible and often interleaving polyrhythms, and the "instruments" - bass, lead, drone - spawn with complimentary defaults.
As a longtime synth nerd, it still amazes me to see beautiful tools like this running in a web browser.
I agree that it's neat to have software synths that can run in the browser nowadays, but this isn't really a good TB-303 emulation. The accent doesn't have a slow enough attack to create the "wow" effect, which is a fundamental aspect of getting any random acid line to sound properly 303ish. Not to take away from what it is, but for a synth that has been cloned and emulated as often as the TB-303, your description is overselling it a bit.
Oil rigs are the worst type of island.
reply