HN user

kalefranz

272 karma

[ my public key: https://keybase.io/kalefranz; my proof: https://keybase.io/kalefranz/sigs/Y4NZOJ26ZB9LFZaCFVQMslckhUTEVYDoIyxE4aYy6U8 ]

Posts14
Comments92
View on HN

Enjoy and appreciate the discussion. Is this in the same neighborhood of why the reworked dict implementation in python 3.6 had insertion order as a detail, but explicitly claimed it was not a feature that should be relied upon? At least until python 3.7 cemented the behavior as a feature.

What exactly does make Tesla a tech company

In asking that question, my guess is that you’ve never experienced being a Tesla owner. And that’s fair. I’m a Tesla owner myself, for full disclosure.

I’ve found that a Tesla is truly a computer on wheels; not unlike an iPhone is a computer in your hand. In many ways, Tesla is a software company that makes their own hardware. Unlike every other auto manufacturer, their software has full and complete control over every aspect of their hardware. Their hardware-software vertical integration is for real. They also have single software releases that deploy OTA to their whole fleet of in-service “devices.” From a software and release engineering perspective, incumbent auto manufacturers are decades behind.

Nearly all car manufacturers have adaptive cruise control somewhere in their lineup

I’d argue the difference is that _every_ vehicle Tesla sells today is cable of being upgraded to the latest state of autonomy—just by an OTA software update and/or flipping some feature flags. While the claim of full Level 5 autonomy without lidar is controversial, it’s possible that most Teslas on the road today will be capable of being upgraded to L5 capability via a software update.

All that said, the QA issues in those photos are pretty jarring. No excuses there.

Conda has an .exe installer on Windows and a .pkg installer on macOS. Both signed by Anaconda, Inc. for the OS. There are RPM and deb bootstrap repos for Linux. Then there’s also the .sh shar file installer.

Former conda dev lead here. Definitely interested in more details regarding what part of the conda experience you found to be a hassle, if you’re willing to share.

Conda can create environments with literally nothing in them. If you’re putting the full-blown anaconda metapackage in every environment, then it sounds like you’re using conda wrong for your use case. Just tell conda to install the packages you actually need.

Hi! I was the conda dev lead for 2.5 years. We work really hard to make sure conda does the Right Thing in unpredictable, almost hostile, environments. It’s a large surface area to guard against, but in general we’ve been incredibly successful.

I hate to hear that you had a bad experience. If it’s at all possible, please provide something on our issue tracker (github.com/conda/conda) we can replicate and write regression tests against. Help us improve on what we’ve missed.

conda seems very very tied to precisely tested version combinations, and (from what I remember - tried and had problems)

Hello. Conda core contributor here. Do you have any more details? Would love to help.

We try to keep version constraints among dependencies as loose as possible. We do actively patch dependency metadata over time, putting upper version bounds on dependencies when incompatibilities eventually arise.

Granted I’ve been reading the traditional style since second grade, I feel like learning this Hummingbird style would be an order of magnitude harder than learning another programming language. Maybe I’m just getting old and the plasticity is hardening.

Yes, it’s still picosat (wrapped in a python library called pycosat). At some point it may be switched out with an alternate SAT implementation, but I suspect SAT in general is very much destined to stay an integral part of conda.

Can you elaborate? Conda packages have full metadata descriptions for system-level dependencies. I agree with you that conflicts and diamond dependencies lurk everywhere, which is precisely the reason Conda employs a SAT solver.

Is this a situation like grsecurity vs Torvalds?

Ha! Conda and Anaconda, Inc. are _not_ like grsecurity. Starting with the fact the Conda is BSD-licensed.

Recounting some of the history will probably provide the context you're looking for.

It's my understanding that the birth of Anaconda (the distribution) and Conda goes back to this statement by Guido regarding package building and installing at a PyData summit in 2012:

It really sounds like you guys' needs are so unusual compared to the larger python community that you're just better off building your own.

https://www.youtube.com/watch?v=QjXJLVINsSA&t=59m10s

This predated PEP 427 (Wheel Binary Package Format 1.0).

Of course both conda and pip/wheels have evolved immensely since 2012, and their evolution has been guided by different constraints. Elsewhere in this thread I spoke about how pip/wheels/PyPA packaging has as it's primary target the site-packages directory, and then branches out from there when necessary. Conda's primary target is the prefix root. PyPA's mandate is to build, install, and manage python packages, which makes something like 'pip install python3' out of scope. Things like 'pip install postgresql' and 'pip install r' are _for sure_ out of scope. Conda has the luxury of being able to install and manage all packages, not just python packages.

Regarding the creep of wheels toward conda packages, and especially the static embedding within wheels of compiled "system" libraries, I question whether it's actually to the benefit of python _users_. No doubt the wheel "binary" format is a huge improvement over eggs for pure-python packages. But manylinux wheels are often built going beyond just compiled python extensions. Rather than describing these "system" dependencies in metadata, and then having pip ensure these system dependencies are present before installing the package, these wheels now implicitly cross the python-only line that PyPA in other cases holds. There are real consequences for users, with the result being that it pushes failure mechanisms back rather forward.

So, because of the differences in scope, my guess is that the python community would think it inappropriate to make Conda an official PEP. Conda will probably someday install wheels (at least pure-python ones); maybe someday pip can reach out to conda or apt-get or yum to ask for non-python dependencies to be installed.

and make conda-forge part of the Python Foundation (instead of a private company)

Conda-forge is actually a community-driven organization completely independent of Anaconda, Inc.

Conda is a great way to get gcc 7.2 on CentOS 6. Anaconda builds all of its packages targeting CentOS 6 for broad compatibility, but with the latest compilers to ensure we have the latest security features compiled in.

There's been quite a bit of discussion about Anaconda and conda in this thread already. Anaconda also takes this distribution approach, and it's targeted specifically at python.