Mark Erikson (web dev professor/historian, OSS Maintainer & engineer at Replay) joins us to talk about the shift from CommonJS to ESM. We discuss the history of module patterns in JS and the grueling effort to push the world’s biggest developer ecosystem forward. Get ready to go to school kids, this one’s deep!

Brett Cannon (our unofficial ambassador to the Python community) is here to help alleviate our pip install anxiety. Along the way, we ask him about Python 4, removing the GIL, what he thinks about Chris Lattner’s Mojo project, Rust in the Python world & way more (of course).

I’m a big fan of Elixir, asdf & TUIs so this one’s a no-brainer share for me. The linked blog post by Mitchell Hanberg goes into the details:

While I find lazyasdf to be an amazing achievement for myself, it isn’t super interesting on its own. Let’s dive into the specifics of how I was able to build and distribute a TUI application with Elixir.

Source code here.

Homebrew project lead, Mike McQuaid:

Today, I’d like to announce Homebrew 4.0.0. The most significant change since 3.6.0 enables significantly faster Homebrew-maintained tap updates by migrating from Git-cloned taps to JSON downloads.

Homebrew creator Max Howell is back with a brand new invention:

tea is a standalone, binary download for all platforms that puts the entire open source ecosystem at your fingertips. Casually and effortlessly use the latest and greatest or the oldest and most mature from any layer of any stack. Break down the silos between programming communities, throw together scripts that use entirely separate tools and languages and share them with the world with a simple one-liner.

All you need is tea.

Bold! I love how many interesting ideas are packed in to this project: pipelines, universal virtual-env, executable markdown… the list goes on. Check out the README for all the deets. My big question is: might Max and the team be thinking too big this time around?

iliana etaoin:

There is a lot of attention on securing “software supply chains.” The usual approach is that you want to try to avoid security issues in your underlying components from impacting customers of your product; and when they do, you want to be able to respond quickly to fix the issue. The people who care about this class of problem are often software companies. The class of components that are most concerning these companies are ones where unpaid hobbyist maintainers wrote something for themselves with no maintenance plan.

This is where the supply chain metaphor — and it is just that, a metaphor — breaks down…

I think we all know this intrinsically, but it’s easy to forget. iliana goes on to describe feelings I’ve heard expressed by a few maintainers recently:

I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. I should be allowed to decide if something I wrote is “done”. The focus on securing the “software supply chain” has made it even more likely that releasing software for others to use will just mean more work for me that I don’t benefit from. I reject the idea that a concept so tenuous can be secured in the first place.

Baruch Sadogursky (Chief Sticker Officer at JFrog) joins Natalie & Johnny to lament the current state of dependency management in Go and other languages. They discuss the problems dependency managers face, possible technical mitigations like SBOMs, people problems that will never be solved by tech, and take questions from listeners in the #gotimefm channel of Gophers Slack.

I’ve been using asdf on my new machine to manage Elixir/Erlang and Node versions and it works like a charm. Highly recommend! There are some complaints in the comments of this post about it being slow, but I haven’t had that problem yet.

An argument in support of software packages that come in the form of a single binary executable (statically linked or portable), that one can just copy anywhere in ${PATH} and execute, without needing sudo, or downloading half the distribution’s packages as dependencies.

An excellent analysis of the age-old dependency management problem:

At this point, I hope the tension is pretty clear: on the one hand, it’s great to keep components small, simple, and composable. On the other hand, it’s terrible to bury yourself in a tangle of different packages, no matter how tiny they are. The Unix philosophy and killing your dependencies pull in opposite directions.

But the author doesn’t stop there. They also offer a potential solution, which shouldn’t be a surprise to anyone, requires a compromise.

A fascinating look at the state of packaging apps for the Linux desktop:

The stability of the Linux desktop has dramatically improved in recent years. Core library developers are finally seeing the benefits of maintaining compatibility. Despite this, many developers are not interested in depending on a stable base of libraries for binary software. Instead, they have decided to ignore and override almost all libraries pre-installed on the user’s system.

And why the author thinks Flatpak (which some believe is the future) is not the way to go.

I am not a fan. I’m going to outline here some of the technical, security and usability problems with Flatpak and others. I’ll try to avoid addressing “fixable” problems (like theming) and instead focus on fundamental problems inherent in their design. I aim to convince you that these are not the future of desktop Linux apps.

Open Source Insights is an experimental service developed and hosted by Google to help developers better understand the structure, construction, and security of open source software packages. The service examines each package, constructs a full, detailed graph of its dependencies and their properties, and makes the results available to anyone who could benefit from them. The goal is to provide developers with a picture of how their software is put together, how that changes as dependencies change, and what the consequences might be.

It currently indexes GitHub, npm, and pkg.go.dev. Plus they recently added a dedicated security advisory page. For an example, check out left-pad’s page which shows 441 direct dependents and 15315 indirect dependents.

Mike McQuaid:

Thanks to all our hard-working maintainers, contributors, sponsors and supporters for getting us this far. Particular thanks on Homebrew 3.0.0 go to MacStadium and Apple for providing us with a lot of Apple Silicon hardware and Cassidy from Apple for helping us in many ways with this migration. Enjoy using Homebrew!

And a quick note on the Apple Silicon support:

Homebrew doesn’t (yet) provide bottles for all packages on Apple Silicon that we do on Intel x86_64 but we welcome your help in doing so.

I’d be surprised if this undertaking could be described as anything less than large. Congrats to Mike and the entire team! Homebrew is a gigantic blessing to developers (who use Macs) everywhere and a shining example of open source done well. 👏

This has been in the works for ~2 years now and finally dropped on January 23rd, 2021. It’s amazing how much work it takes to upgrade a community as large and broadly-interested as Python’s.

Getting the de facto tool for installing packages off Python 2 seems like a pretty moment in that effort to me, but I’m only a casual observer/fan of the language. I’d love to from folks who use Python on the daily.. Is this a big deal?

Sam Soffes:

Today, my new 13-inch MacBook Pro arrived! I was super excited to get it out of the box and set it up. This thing is fast! I am already very impressed. When I started setting up my development environment, things started to get a little frustrating. Have no fear, it’s solvable!

The biggest issue for me was Homebrew. According to this issue “There won’t be any support for native ARM Homebrew installations for months to come.” No big deal though. Homebrew can work just fine with Rosetta 2 and some things work natively.

Jesse Donat:

Go has a problem. Go modules place a strange naming requirement on modules version 2 or greater. Module names on modules v2+ must end in the major version ala …/v2, and communication of this rule has been weak. It’s non-obvious, and the community at large does not understand it.

I have seen many very large projects including Google owned projects get it wrong.

I brought the issue up at my local Go meetup, and no one had ever heard about the rule. They were very skeptical the rule existed at all.

Jesse goes on to tell the history, explain the problem in-depth, and suggest next steps for the Go Community.

There are a whole range of ways to package your Python software: Wheels, Pex, RPM/DEB, Conda, executables, Docker images, and more. Which ones should you use? In this overview you’ll learn why they all exist, the pros/cons of each method, and how it deals with things like code distribution and support for multiple applications.

I’m a bit late to the party on this one (was out on vacay last week), but my oh my did Randall Munroe hit the nail on the head. I have a feeling we’ll be referencing xkcd #2347 for years to come…

Oh, and in case you’re not yet aware, xkcd’s image title attributes always carry an additional punch-line/comment (which is a brilliant way to make it worth visiting the site each go-around). I’ll save you a click, just this once:

Someday ImageMagick will finally break for good and we’ll have a long period of scrambling as we try to reassemble civilization from the rubble.

Johanna Larsson built the super cool Hex Diff tool for the Elixir community. What does it do?

In short, you input any Hex package name and a version range, and it will generate a highlighted git diff for you, right there in your browser. Not only that, but you can also share the link to the diff, and even highlight a specific row.

In this post on her blog, Johanna goes into the details of how she built the project, how it works, and issues she ran into along the way.

Carmen, Mat, and Jon are joined by Steve Francia and Julie Qiu to discuss the new Go.dev website. What was the motivation behind it? What technology was used to build it? How are they working to make package discovery better? And what resources are there to help you convince your manager to use Go on that upcoming project?

No more waiting for your bundler to rebuild your site every time you hit save. Instead, every change is reflected in the browser instantly.

This relies on ESM (Mikeal gave a great rundown on the current state of things on a recent JS Party), so it’s not for everyone. The homepage has rundowns on who should use this, who should avoid it, and how to get started.

Brought to you by the fine folks at Pika.

ES Modules are unflagged in Node 13. What does this mean? Can we use them yet? We chat with Mikeal, our resident expert, and find out.

A wonderfully snarky take on the ongoing challenges with dependency management in JavaScript.

PURESCRIPT, NPM — In the hours following another package disaster on npm in which a lone developer killed more than dozens of CI builds and caused serious warnings in thousands of others, developers of the only community where this kind of disaster routinely occurs reportedly concluded Monday that there was no way to prevent the disaster from taking place.

The exodus from npm continues. Laurie Voss:

Not to bury the lede: I have resigned from npm. I made the decision to leave in early May, and my final full-time day was July 1st, but as a co-founder it takes a long time to untangle yourself so I will be helping with transition-related tasks until they are wrapped up.

If you watched ceej’s The economics of open source, then you already heard about Entropic. It’s only a month old, but the federated package registry already has some working code and a fleshed out manifesto.

Now’s not the time to use Entropic, but now is the time to get involved.