While working on a PhD in technology and education, I thought that it might be worth creating a SaaS for people to teach whatever they want. This was back in early 2008, when such sites didn't exist. I assembled a team, and we made some progress, and even got a commitment from one funder. But I didn't really understand how to manage the team, and everyone was working very part-time on the project, and we didn't really have anything serious we could show, even after a few months. And the funder was only willing to invest if we found a second investor, which we didn't. So we ended up abandoning the project.
I think that we had some great ideas, including guiding instructors in the creation of online classes using the best proven pedagogical tools and theories. You could connect lessons to standards (if you were in a school, or wanted to be associated with one), or could do it free-form, or could use templates of various sorts.
I ended up finishing the PhD, so I can't complain too much! And as I wrote, I was probalby not a good person to run a startup; I'm much happier with my life as a bootstrapped freelancer. But it was hard to realize that I spent a year or so working on this with very little to show for it -- especially knowing that it might have thrived under a more experienced leader.
A lot of people I know, including many of my students, first heard about uv as a lightning-fast replacement for pip. That's what piqued their interest, and that's also more or less where they stopped. Just yesterday, someone was asking me about whether uv knows about handling different versions of Python, or if it only installs packages.
So your points are all valid -- but I'm trying to address pain points people have repeatedly raised, and that I myself experienced, and flatten the learning curve for as many people as possible.
I dunno, every single conference I've attended over the years had at least one talk trying to make sense of packaging -- downloading, installing, venvs, creating wheelfiles, and distributing to PyPI. It was nice to say that you could choose your own tools, but it was a huge, confusing, daunting mess for many people.
I had some thoughts about how things could improve, but the core developers said that anyone with their own ideas had better think through all of the implications, because packaging is super hairy.
The uv folks basically took that as a challenge, and said, "What if we have one package manager that replaces literally everything else in the packaging ecosystem, hiding the stuff that people find confusing or annoying?" Color me impressed; they really did it.
Sorry to disappoint! I can tell you that many people I've met, including those who have read the documentation, kept asking questions about how to use uv. This article is a summary that I came up with, based on my experience and theirs.
System-wide package installs are a weird quirk of my own work, since I'm doing very little product development and lots of one-off classes. I'm not at all recommending that "normal" developers do this, and I make sure to say that in all of the courses I teach.
I teach Python professionally, and constantly get questions from my students about how they should be using uv, and how to integrate it with pip, pyenv, venvs, and the like.
When I shared this post with them, my students said that it clarified things they didn't previously understand, even after reading the documentation. Part of the problem is that the documentation describes lots of options, rather than explicitly encouraging one particular path and model.
So I don't think it's just me; people are excited about uv, but aren't quite sure how to use it. But hey, I could be wrong!
As for your comment about venvs -- I teach them, I demonstrate them, and I use them when I work on programming projects.
I mostly create one-off Jupyter notebooks, which don't (in my opinion) merit their own venvs, because I don't care about locking versions. That said, I'm switching everything such that every class I teach will have not only a GitHub repo, but also a uv project, and thus an implicit venv behind the scenes. I still don't have to worry about package conflicts, but I want to be more in line with community conventions.
I have something of a following (newsletters, social media), gave two talks at PyCon, and even had a booth advertising my training services. So at the risk of sounding like a total egomaniac just for responding, let me say a few things:
1. I absolutely, positively love meeting new people at PyCon, regardless of their background, level, etc. I learn new things from just about everyone I meet, and that's a huge part of the fun for me. I'm frustrated that I don't get a chance to just meet and chat with more people during the conference, and actively try to eat meals with people I don't yet know so that I can get to know them.
2. Part of the greatness of the Python community is that we realize other people, regardless of their fame, are just that -- people. They were unknown at some point, and people were nice to them. So they'll probably be nice to you, too.
3. Every community has jerks, Python included. If someone famous isn't nice to you, then just ignore them from that point on, and concentrate on the numerous nice people. It's not worth getting riled up or upset about it.
I think we can all agree that masking is super annoying. We can also agree that if everyone were to mask 100% of the time, then we would be in a safer world, with less spread of disease.
But we all live with some level of risk. Keeping the risk level at or near zero isn't realistic, or something that most people want. We cross the street, travel in cars, etc.
I find it weird that PyCon had a mandatory masking policy, when medical conferences staffed by doctors and disease experts don't have such a policy any more. And I'm guessing that PyCon's policy was made by well-meaning people who aren't doctors or medical experts.
My suggestion -- and yes, I wrote this in my PyCon follow-up survey -- is that our masking policy follow whatever the CDC, AMA, or a similar body is doing for its conferences at the time PyCon takes place. If the experts require masking, then we should do so, also. And if they don't, then we should encourage people to mask if they need or want to, but we shouldn't force it upon everyone.
In other words: PyCon should make decisions about the conference and Python-related things. Medical decisions should be left to outside experts.
how much did people actually follow the mandate? I looked through the pictures, and it seems to be ~not at all for picture/social situation, and maye 50% for general?
In talks, in hallways, and at the expo (i.e., company booths), I'd say adherence was at least 90 percent.
But whenever there was a chance to take the mask off, people did. If there was food around, people immediately ditched the masks and stayed with food or drink in their hand to justify keeping the masks off. I was at one small (10-person) session where everyone agreed to keep masks off, gingerly making sure that no one objected. We then all made sure to have drinks in front of us to "justify" doing so.
And when people went outside, the masks were off. At the PSF member lunch, where we ate together, masks were off as soon as we got food. At the PyLadies auction, where we (again) ate together, people were also without masks. I'll note that the auction took place in the same room where talks had taken place several hours earlier, with strict mask enforcement (and adherence).
Bottom line, people were generally willing to follow the rules. But there was a lot of grumbling about why there should be a mask mandate in 2024, and what the justification was for having one.
I attended and I would say there was 98% compliance. The policy was that masks off was OK outside, while presenting, while eating, and briefly when posing for photos.
Kit! Your post is great! And I enjoyed getting to know you at the PyLadies auction, too.
PyCon is overwhelming and delightful in every way -- and it just gets more so every time I attend. That said, you managed to see a ton of amazing stuff and people, which is quite impressive.
I think that we had some great ideas, including guiding instructors in the creation of online classes using the best proven pedagogical tools and theories. You could connect lessons to standards (if you were in a school, or wanted to be associated with one), or could do it free-form, or could use templates of various sorts.
I ended up finishing the PhD, so I can't complain too much! And as I wrote, I was probalby not a good person to run a startup; I'm much happier with my life as a bootstrapped freelancer. But it was hard to realize that I spent a year or so working on this with very little to show for it -- especially knowing that it might have thrived under a more experienced leader.