I'm sure you're familiar with package managers for your OS, even if you don't use them.
On macOS, we have Homebrew, Chocolaty on Windows, and Apt, Yum, and others on Linux.
But if you want to install Python applications, you typically have to fall back to managing them with pip.
Maybe you install them for your account with the --user flag.
But with pipX, you get a clean, isolated install for every Python application that you use.
And if you distribute Python apps, pipX is definitely worth considering as a channel.
On this episode, we have Chad Smith, creator of pipX, to tell us all about it, how it works, and how to use it.
This is Talk Python to Me, episode 371, recorded June 22, 2022.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy, and keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode.
This episode is brought to you by Mergify.
Take control of and automate your GitHub workflows.
As well as the Python at Scale Summit conference being held in October.
Reconnect with your data science colleagues this year.
Transcripts for this and all of our episodes are brought to you by Assembly AI.
Do you need a great automatic speech-to-text API?
Get human-level accuracy in just a few lines of code.
Visit talkpython.fm/assemblyai.
Chad, welcome to Talk Python to Me.
Thanks, Michael.
It's fantastic to have you here.
I and many listeners are such a fan of PipX and really just love to have that tool around to allow us to use Python libraries and commands like applications.
And it's going to be so fun to talk about.
And if you're out there and you haven't heard of PipX, you're in for a treat.
So before we get to that, though, let's start with your story.
How do you get into programming in Python?
So I got into programming back when the internet was kind of like really popular with GeoCities, like early web development type stuff.
This is the time when people had like the animated digging Giphy.
Yeah.
And like a lot of sites were still permanently under construction.
Yes.
And flashing text and stuff like that.
So I thought that was pretty cool.
I messed around with some GeoCities pages.
I wrote a little bit of JavaScript to where you can like hover over text and it will change the image and stuff like that.
And I kind of messed around with web pages for a while, but I didn't really get too serious with programming, with web development until later, much later.
So when I got more into programming was in college.
I went to, I got a degree in aerospace engineering.
And so we did like kind of like scientific computing.
We used MATLAB a lot.
So I used a lot of MATLAB in college.
And then in my first job, we did a lot of MATLAB.
So in the aerospace industry for making airplanes and like control systems, we use MATLAB a lot.
And so I kind of started hacking out MATLAB and making like a bunch of programs and automating stuff, not really going into other programming languages, which were probably better suited for the job.
I just kind of did everything in MATLAB.
That's the way I think most people do it is they have a set of tools to pick from that they know how to work with them.
And they're like, well, which one of these is going to be best?
And if your programming environment is MATLAB, then, you know, that's not a terrible choice, really.
Yeah, I got like really into programming MATLAB and then eventually ended up at a job where I got to start doing a little Python.
Nice.
What kind of airplanes were you working on?
First job was on the space shuttle, which was, which has been retired.
Then I worked on like, I worked for Boeing.
Of course.
Oh, that's fantastic.
Yeah, I worked from the 747, 787.
So I worked for Boeing.
So Boeing worked on the space shuttle and as well as obviously a bunch of other planes.
And then none of the Python work was there, though.
And the Python stuff started at a startup funded by Google co-founder Larry Page.
So it was an EVTOL, electric vertical tick off and landing plane.
So it's like a small plane.
It was a startup.
It was a small company.
And we needed like basically some tools to be made.
And I didn't really know Python, but I like to just take on new challenges and learn new things.
So my first experience with Python was with Python 2 and working on a Django app.
It was an app to track all of the parts and weights and moments of inertia of the aircraft.
Another project was like called a protocol compiler.
So all the C code that ran on the avionics was a lot of it was generated.
A lot of the inter device communication was generated from this common protocol definition.
And so this was all written in Python.
So we could generate safety critical C code.
We could generate documentation about the code.
We could generate tests where we had like hardware in the loop tests.
And so that was where I started to run into issues with challenges with packaging and getting dependencies installed on folks computers.
Because if you wanted to build the flight code, you needed to have a bunch of packages available.
Right.
And so, you know, you had to have maybe some foundational thing in order, some libraries and other things.
And you probably didn't want to teach necessarily C people how to set up Python and virtual environments and all that kind of stuff, right?
Exactly.
Or documentation writers.
Yeah, exactly.
And yeah, it was a small company.
So there wasn't really a Python expert in house.
So we kind of made a lot of the mistakes and I had to go into the infrastructure side too and try to build all that out.
And so, you know, we started out with, I think we started out with pseudo pip install and that was how we got our things installed.
Yeah, for sure.
Well, you talk about this, the small business or a small company you're at and sort of bouncing off the walls and just figuring it out yourself.
But you were also at Boeing, which is a non-small company for my looking in from the outside.
Yeah.
I know a lot of people, they definitely dream of or look to get hired at these really large companies.
And yeah, I feel like there's a huge advantage to at least spending a little time in a company like this VTOL one you talked about where you're taking on a lot of responsibilities and you're kind of working together to figure out stuff rather than slot it into like a narrow slice of what's getting done.
What do you think?
What was your experience in those places?
Well, so Boeing did offer opportunities to let you kind of like improve processes and stuff like that.
But the scope of what you're working on at a small company, trying to build a similar product.
I mean, you have a smaller team with no like legacy or decades of history building stuff.
You're kind of just inventing it as you go.
So yeah, there's a ton of stuff to experiment with and take on and learn from.
Yeah.
Cool.
How about now?
You're at another small company, right?
Yeah.
I'm at a small company called Meta.
I work for the, I work for Reality Labs and I work on developer infrastructure here as well.
I work on things like language services, debuggers, and VS Code, VS Code extensions.
Cool.
Do you have any exposure to the Cinder project or any of the stuff going on over there?
No, I'm aware of it.
I think it's super cool, but that's an Instagram thing really.
And so it's not really something that I use day to day.
Well, it looks like it's going to become a Python thing in little bits and pieces.
Yeah.
The pieces of it are being pulled over.
Like we just talked about PEP690 and lazy imports, and there's a couple of other things
people are working to move in.
So not the whole thing, but some of those features and improvements make it to all of us.
Yeah.
That's the great thing about Python is if you come up with a good idea, the community is
very open and willing to adopt new ideas.
The best ideas win and can be continuously improving the language.
Yeah.
That's pretty fantastic.
So let's start our conversation here at a little bit higher level than just PIPX.
And let's just talk about packaging a little bit.
So let me switch over here to this project.
So you have over at chadsmith.dev, which is a great domain name.
And I'm impressed with a name like Chad Smith that you can get it just straight up as your
domain name.
Because as Michael Kennedy, all the Irish politicians are all over me.
I got to go with some crazy variation to come up with it.
But yeah, that's cool.
That's a great domain name.
And over there at slash python-packaging, you've got the big list of Python packaging and distribution
tools.
You want to tell us about this?
Kind of gives you a high level of like, what are the options, right?
Yeah.
So a lot of times questions come up about what tools are out there, which tools do what.
You know, it's a big world in the packaging, in the packaging, in the Python packaging world.
And I wanted to make something that was not opinionated and just kind of factual.
Like here's some data, here's some information about these.
You can decide for yourself.
It's not trying to persuade you to use this.
It's not like saying this is my tool.
This one's the best.
And this came about from PIPX's documentation where one of the other questions on PIPX was
like, what is it and how does it compare to other things?
So I had kind of a list on the documentation and it kept growing.
And I was thinking, you know, this could be its own thing because I don't want to PIPX
documentation too big.
Make it a survey of all the other things that it competes with or could have been put alongside,
right?
Yeah.
So this is an interactive web app table type thing.
And it pulls data from GitHub's GraphQL API.
And it lets you kind of like select different features and filter on those.
You can compare and group tools together.
So on the top left, you'll see there's like a bunch of little blue words with blue backgrounds
and you can click on those.
Yeah.
And if you click on them, then it'll filter down the table.
And so if you want to find tools that have, I can install and publish, you can click on
like install CLI apps and also publish, publish packages.
Nice.
This is a great little UI.
It reminds me of an app I wrote once and I'm having nice nostalgia here.
It's cool.
So you can sort of click on these little categories or filters and turn multiple ones on and off.
So if I want virtual environment management that can install libraries, well, apparently
there's none of those.
But if I want to build packages and install CLI apps, well, I guess PDM is my choice, huh?
Right.
That's cool.
So maybe one thing that we could do that would be nice is maybe we could go through and highlight
some of the more notable packaging solutions or options as we go through here.
You know, PipX being one of them, we'll get to that a bunch more, but want to maybe give
us a bit of a rundown?
Like probably the first really notable one is Conda.
People are super familiar with that, right?
On the data science side.
Yeah.
So Conda is kind of like a more ambitious way to create environments and it kind of
makes its own ecosystem.
I personally haven't used it, but I know it's pretty popular, like you said, with a scientific
community.
So it also can be used to make C libraries too.
Interesting.
Yeah.
It's certainly the claim to fame of Conda and Anaconda and Miniconda, all those things
is you don't have to have the build tools for all the libraries, the transitive closure
of the libraries you want to use, right?
My understanding is it's its own packaging system.
Like you don't pip install from it.
There's some other parallel ecosystem.
Right.
Exactly.
And I feel like to some degree with wheels, we're a little bit closer than we used to be
with pip directly, right?
Pip install wheel can just drop in a thing, whereas previously stuff had to happen on your
machine to finalize that package.
Yeah.
Wheels are specific to your Python version, your operating system.
And so, yeah, that can just be basically unzipped and used.
Yeah.
That was fantastic, except for the first couple of weeks of the M1 platform, the Apple Silicon
M1s.
You try to install something.
Nope.
We don't have a wheel for that platform.
What do you mean you don't have a wheel?
Come on.
I think that's pretty far in the past now.
I haven't run into that problem for a long time.
Cool.
Another one on here that's clearly pretty popular and in this C generating native code category
is Cython.
Yeah, Cython is super interesting and it takes advantage of one of the pretty cool features
of Python itself.
So Cython can generate C code from your Python code and it generates shared objects and shared
objects are able to be imported directly from Python.
So you can make a basically like a wheel that is native code built from your Python code.
And if you have code that is really run really frequently, like a really hot path, that Python
is just a little bit too slow for you.
You can really easily use Cython to convert that into C and make a shared object and then just
use that, but just that module or just that function that you wanted to speed up.
There's some interesting examples of that.
For example, UV loop, which is the fast drop in replacement for asyncio, right?
That was written in Cython and built on top of libuvc library, I think.
Right now, here's one of those tight loops where this is the while true or the for in
loop that does all the magic, right?
And so doing something like this makes a lot of sense.
Absolutely.
Yeah.
I was surprised how easy it was to use Cython.
You can just basically run it, point out a file and it just converts it to C.
And you can import it too.
It makes the shared object.
It's just kind of like you just run the command and it's just magically turns into something.
Hopefully it all works, but it turns into something that runs a lot faster.
Yeah, it really is neat.
And if you use the Python type hints, it can get even a little bit better.
Yeah.
Or if you go farther, you can import the Cython integer instead of just a regular int and so
on.
Yeah.
And now Cython has typing in Pythons.
So Cython also has its own kind of parallel language where you write like PyX file and you
have Cython annotations.
But now with type hints becoming more prevalent in Python itself, there are also Cython type hints,
which allows you to write just straight Python code, but Cython still recognizes how to,
convert it to a statically typed C type.
Right.
I think that makes it way more approachable for many people because they don't feel like
they have to go learn something different.
They're like, well, if I just put type hints on this, maybe different type hints.
Yeah.
And we're good to go.
Yeah.
Which is pretty cool.
Yeah.
All right.
That question from the audience from Juergen.
Hey, Chad.
What about Buildout?
Made up your mind on whether to include it?
What's the story with Buildout in this?
On the Python packaging table, there were some suggestions in the issue tracker.
And one of them was around Buildout.
And it was something I hadn't heard of before.
I'm still considering whether to add that or not.
I think I will.
Leaning towards yes.
Okay.
I don't think I've done anything with Buildout.
Okay.
Very nice.
And also, I saw that Py2App could get...
I don't think Py2App was there, was it?
It wasn't.
Yeah.
So what's the criteria for being on that list, I guess?
Yeah.
I just kind of made it as a...
Started just as the comparison to PIPX where people might be confused or wonder which one
to choose.
And then it's kind of just grown organically, just things I thought were interesting or relevant.
I think they should be something that is still...
So it's something that people would want to use because there's a lot of changes in the
packaging landscape and there's a lot of stuff that kind of gets left behind that you really
wouldn't want to use anymore.
There's new tools being made.
There's new standards being defined.
So I want it to be something that's kind of like modern, relevant, something that's like
encouraged to be used.
I was concerned it was a little bit like maybe older and like I hadn't heard of it and you
haven't heard of it.
So I wasn't really sure how, you know, if it was something that we should still encourage
folks to use or not.
Yeah.
Here's an interesting...
Have you checked out the PSF developer survey results this year?
I have not.
Yeah.
So they have a section on basically which tools related to packaging do you do to use?
And they break it down by popularity, which I thought was pretty cool.
That's really interesting.
Yeah.
So for people just listening, it's 81% of the people say they use pip and then 32% of people
use VNV.
I feel like that's pretty low.
Honestly, it should be higher than what's going on there.
But you've got 30% of people use containers, 23% use virtual ENV, and then 22% is condo.
We've got poetry, PIP, ENV, Afflit, PDM, and others are like way down, way down in the list
there.
Yeah.
So anyway, does that strike you as what your mental model you had in mind a little bit?
Yeah.
Roughly.
There's a few surprises in there.
But I think all those should be in this table.
If they're not, I'm going to have to check out that list and update the table.
Sure, sure.
Well, you know, maybe not the container stuff, right?
Because that's kind of just like I have a virtual machine.
I mean, virtual machines are also in there, right?
It's like, which I think means I have a virtual machine, so I don't care if I just trash it
and just bust its system, like customize its system Python.
This portion of Talk Python to Me is brought to you by Mergify.
It's an amazing tool to make you and your team way more productive with GitHub.
Mergify is all about leveling up your pull requests.
Some of the features include automatic merges.
You explain the conditions for an automatic merge and Mergify will take care of merging the
pull requests as soon as it's ready.
Automatic updates.
They merge your pull requests serially on top of each other, so there's no way to introduce
a regression.
Merge queues.
Merge the urgent pull requests first.
Organize your PR priorities as you wish, and Mergify will merge them in that order.
Backports.
Mergify will even copy your pull requests to other branches once the PR is merged, shipping
your bug fixes in multiple branches automatically.
Mergify features allow you to automatize what you would otherwise have to do manually.
By saving time, you and your team can focus on projects that matter.
Mergify is coordinated with any continuous integration and is fully integrated into GitHub.
They even have a startup program that could give your company 12 months of credit to leverage
Mergify.
That's up to $21,000 in value.
Start saving time today by visiting talkpython.fm/Mergify to sign up for a demo and get
started, or just click the link in your podcast player show notes.
Thank you to Mergify for sponsoring the show.
Thank you.
For me, when I set up my servers, I don't do that.
I actually create a virtual environment for the apps running on that server, or maybe multiple
ones, but often it's just running one service.
So I just create a virtual environment for it, just for the isolation alone.
So it doesn't say, well, you can't use this version of some library because it's being
used by some part of the system.
You can really cause yourself huge headaches messing with parts of the system.
Like one time, I think I tried to rename Python.
I think I repointed my Python 3 alias to a different, like a newer version of Python 3,
because I wanted to use, I wanted that to just be what it used.
And pretty sure my computer didn't start after that.
Yeah.
While I just have this page up, I just want to also show that PipX does show up over here
on tools for installing packages instead of managing it.
And yeah.
Oh, very cool.
Coming along there.
Pretty cool.
By the way, there is a PEP I saw around not clobbering system installs, where you have like
Ubuntu managing its own Python packages, and you install to it, or you uninstall something
and kind of like mess up your whole system.
There's a PEP out there to address that and to not mix things in there.
Oh, that's cool.
I feel like almost Ubuntu and those different systems could say, we're going to have our
own isolated environment for our stuff.
And what you want to do, even if you just run Python straight, that's going to do something
else.
But yeah, I don't know.
I don't know the mechanics of making all that happen.
There's a lot of pieces involved there.
Yeah.
The isolation is definitely useful.
Okay.
Back to the build stuff.
Maybe there's a couple of others here.
Like we've got the sort of what I would call pip alternatives.
We've got FLIT and Poetry, right?
Those are maybe, yeah, FLIP and Poetry and PIP, E and V. I guess those are all in a similar,
I know that I might be painting that with too broad of a brush, but they're all about installing,
working with your environments, installing stuff into your environments for apps you're
building, right?
Yeah.
And PyFlow as well.
And Hatch.
There's quite a few.
Yeah.
I'm not familiar with Hatch.
Tell me about Hatch.
I have heard Hatch mentioned, or I think I've seen it around for a while.
I never really used it.
But then the creator of Hatch recently added a pull request to PipX to use the Hatch backend.
So with PEP 5.17 and 5.18, you can basically anything you want, install, build your wheel,
build wheels.
So you can have different backends to build a wheel.
So Hatch has one called Hatch.
Right.
This is actually now in the packaging, the Python packaging documentation.
Like if you go to like the Python packaging website, like I think it's packaging.python.org,
there's instructions on how to like build, to build a package, to distribute it.
And it uses the Hatch link backend, which is a big achievement now.
It's no longer telling you to use setup.py, but it's telling you to use this new tool called
build.
Right.
Which is also on your list right at the top.
Yeah.
And it's alphabetical.
So yeah.
Well, it wins with, I guess the A, A, A, A, A, V and V is maybe got a spot to still take
the top notch there, but.
That's a good idea.
Nice.
You do also have things like GitHub stars and stuff.
Can you sort by them?
Yeah, you can, right?
I just added the star emoji and I think it screwed up the sorting.
So I'll have to work on that.
Oh, it sorts by alphabetical then with the start of the star.
Yeah.
Okay.
The challenges we run into.
Yeah.
So this is really cool.
Anything else you want to give a shout out to while we're here before we move on?
Py03 is super cool.
I played around with that.
So Py03 is a way to call Rust code from your Python code.
So kind of similar to Cython, except it doesn't generate Rust code for you.
You just, you have to have something already built in Rust, but it's pretty easy to use.
There's a really popular Rust tool called RipGrep, which is like grep, but rewritten in Rust
with a nice API and it's super fast.
And one thing I tried just to kind of like learn Rust and learn Py03 was to write an API in Python
that called into the RipGrep Rust code.
Right.
Okay.
Cool.
And that actually worked pretty well.
I was pleased with the development process and how fast it all ran.
Nice.
All right.
Let's see.
One more bit of follow up on this that Juergen says,
Tox will also use Hatchlane with version four, which is pretty cool.
Nice.
Yeah.
I think that it's probably going to gain a lot more traction.
Yeah.
It sounds like I need to learn about Hatchlane and Hatch.
Pretty cool.
Another thing that's interesting here that is sort of in the same space that we could talk about
is PEP 582.
To me, PEP 582 feels a lot like node modules for Python.
Sort of that.
Where is the, what is it?
Project.json and then the node modules folder next to it, right?
There's a folder and it has a name.
That's where your packages get installed to.
And if you run Python commands below it, it will sort of traverse the directory up looking for that
to find its effective virtual environment instead of the traditional virtual environment behaviors we all know.
Right?
Right.
Yeah.
What are your thoughts here?
I sort of stumbled across this.
I don't remember how I found it, but when I saw it, I was like, oh my gosh, this is incredible.
I can't wait for this to land.
I'm a big TypeScript developer.
I like TypeScript, I like JavaScript.
So I can kind of compare the two because I do a lot of work in both.
And when I saw this, I was really excited.
Right.
So you're like, this is the node version for Python.
Yeah.
There's a lot of headaches with global installs and globally installing packages and conflicting with the OS.
And so having that extra step to always activate a virtual environment or create one or delete one or recreate a new one, it can get tedious.
And so, and it's also a bit, it's part of the environment, right?
Like Python packages is this file on a file system.
You know, it's there.
If you want to start over, you just RMRF the folder and you can start over.
So when I saw this, I was really excited and acceptance of it would be imminent and we'd be using Py packages very soon.
I did too.
Like, oh, this, we're, the next release, the world is different, right?
Yeah.
And so you can see on the, right.
Yeah.
And yeah, it says this is targeting version 3.8.
It's still in draft status.
And that was 2018.
So it's four years ago.
So one thing I want to mention is, as you mentioned, this is like node modules for Python.
And one of the authors of the pet mentioned that he, he doesn't want folks to think of it like that.
Although it's not a bad analogy, but it's more like an auto activated virtual environment or automatically recognized.
So he wanted to think of it like that because he didn't want to have nested Py packages where we can have this complicated nesting of each package has its own Py packages.
Like a fallback as you go up and yeah, yeah, yeah, yeah.
I hear you.
But to me, it seems like it would simplify a lot of stuff.
For example, if I have a cookie cutter template and I want to just make sure that that project has its own environment, the cookie cutter could just create this folder at the top level and you're kind of good to go.
You know what I mean?
You don't have to do a bunch of virtual environment stuff.
It just, that's the one, right?
Yeah.
If you've got working with people who are new to Python, you can just say here, unzip this and run it and you know, it'll start out empty, but maybe the first step is to verify all the stuff is there, but you don't have to, you know, there's just that, that bootstrapping to get started, which as you gain experience, it's no big deal.
But I often encounter people who are new to this and they kind of bounce off it, which is unfortunate.
When you come across a project or when, especially someone newer to the language comes across a project and they see instructions are pip install this thing, it's really kind of a loaded instruction to give someone because you might be basically breaking things in the process.
You might be setting yourself up for some kind of failure.
Right.
It could get installed to their system.
They might not have permission to install it to the system.
There's a lot of stuff going on there.
It also might install a version of a package that another tool requires a different version of because it'll just kind of update it with what it needs.
If there's an outdated version or something, it'll just give you a newer version, which may inadvertently break some other tool that depends on that older version for some reason.
Right.
And then all of a sudden your fail to ban or your firewall or something stops working.
You're like, why did that stop working?
Or glances or some other tool.
You're like, I thought that was part of my machine.
Now it doesn't work anymore.
And, you know, your little test project or tutorial broke it.
Right.
Yeah.
That's probably suboptimal.
Yeah.
So this was exciting to me because, you know, you could have pip install something and it would go to this PyPackages directory potentially.
You wouldn't really have to worry about any other side effects or any kind of environment that you're affecting.
Maybe someday.
Yeah.
Not for the moment.
Yeah.
Well, we do have this other tool called PipX that does manage this somewhat for a certain class of problems.
Right.
But this is more for building packages and applications and stuff.
Not so much external tools, but still.
Yeah.
I think there are different use cases.
Because I think this one's more for libraries, building your library or not necessarily the app.
Yeah.
Well, you pointed out some implementations or experimental things going on with this one.
So let's see here.
Yeah.
So you got PyLock here.
This is you, right?
Yeah.
That's fine.
So PyLock is a drop-in replacement that imports packages from this directory.
And it's like an experimentation or an experimental implementation of this, right?
Right.
Yeah.
So I called it Python loc was the idea, like local, loc stand for like.
Location.
Yeah.
It stood for like local packages, I was thinking.
I don't know.
The name's still a thing could be revised, I guess.
But I saw the pet, but I thought it was super cool.
And I thought, hey, maybe I can hack something together and let people try it.
Because I think trying, discussing how something might work and actually using it is kind of like
looking at a picture of somewhere you want to take a vacation and actually going there.
You know, it's like going to a place versus just kind of like hearing description of it.
So if we make something we can play around with, you can see, oh, this, I thought this would
be cool, but it actually is way harder to use.
Or maybe it's exactly what I thought I wanted and it's great.
And, you know, let's accept the pet.
So I made this just as a way for folks to easily experiment with this kind of workflow.
Yeah.
Okay, great.
And people can play with it.
Although, who knows where this idea is going?
I still think it has legs, but yeah, it's been chilling for a while.
And then there's PDM.
I've heard of people using PDM and does this follow?
Yeah, it seems like it follows the same idea, right?
Tell us about PDM real quick.
Yeah.
So PDM is kind of like poetry.
I mean, it uses PEP 5A2.
So it uses the PyPackages directory.
But yeah, it's similar in the idea of poetry or similar tools like PIPenv and all the ones
you mentioned, PyFlow.
So it creates and modifies the PyProject.toml file.
It can add its own metadata to it.
It can build packages.
It can publish packages.
I'd have to consult that table.
But yeah, I think it's kind of like an all-in-one tool.
And that also uses PEP 5A2.
Right, exactly.
So it does a lot more.
But it does happen to also use this idea, right?
Right.
And in the discussion on...
In the PEP 5A2 discussion on where all the folks are discussing the pros and cons, the developer
of PDM mentions that, like what his experience was with it, some of the tweaks he had to make
to the PEP to make it work for him.
And I saw that there was some interest in it.
And also PyFlow is another tool similar to PDM.
It's written in Rust.
But I saw, I think Brett Cannon was interested in working with those two folks to maybe flesh
out PEP 5A2 a little more because they have some real world experience.
Okay.
Interesting.
Yeah.
It doesn't sound like the PEP is dead.
It sounds like it's stalled is more maybe how I understand it.
Yeah.
I think one of the...
So there were two original authors.
One of them is no longer interested in pursuing it.
But the other is, I think he's just been a little bit busy and hasn't had time to dedicate
to it.
But I think there's still potential for it.
Sure.
Okay, cool.
Well, let's move on to the star of the show, PipX.
How do you tell people about PipX?
PipX is a tool to install and run applications that happen to be written in Python.
I was going to say, too, I think of it as like Homebrew or AppGet or Chocolaty or one of these
package managers where I just want to get this command or this application on my computer.
I don't really care what it's written in.
It's probably written in something tough that I have to install weird dependencies for or
I got to have some odd compiler and I don't want to deal with it.
I just want to...
I know it if I type brew install handbrake or something, like I'll have that.
Right?
That's the way I see PipX is there's all these cool commands and CLIs and utilities in Python
and they just happen to be in Python, right?
Like we as Python developers care a lot that that's the case, but we just want the commands,
right?
And with PipX, you can just type PipX, say, install pytest or PipX install Glances or some
other cool library.
And sure enough, you'll have it installed, right?
Yeah, that's the idea.
One of the goals is to take away difficulty for end users to install a tool.
A lot of times the instructions are like, you know, install with Pip.
And like I said, you can have problems with that.
That's kind of a loaded instruction sometimes to give people, especially if they're not Python
developers.
If you as a Python developer, if you see that you wouldn't really have trouble managing that.
But as a lot of folks, a lot of folks out there that just want the tool and the instructions
are kind of like install, create a virtual environment.
Now run the pip from that environment to install this tool.
Now search into that bin path and there's your binary.
Like that's not really the easiest way to get end users a really cool program that you wrote
that happens to be in Python.
Right, right.
I want to have this program accessible.
Oh, wait, did you forget which virtual environment you installed it into?
And did you forget to activate that or whatever, right?
So this solves a lot of those problems, which is fantastic.
Juergen again says, as you said, install and run Python applications.
Does this refer only to CLI or even web apps?
I'm not sure I understand the question.
Certainly CLI apps.
I'm not sure what a web app is in terms of this question.
Sure.
Well, I guess maybe just can it install stuff more broadly?
Like if I had something maybe that was built with GUI, for example, G-O-O-E-Y, like that
GUI framework, or I have something that was installed or built with some other tool.
That when I run it, maybe I don't get a CLI experience.
Maybe it installs Flask and opens a browser or something like that, right?
I think that's the question.
Yeah, absolutely.
That's actually where I found the need for PipX most.
And the tool I made that happens to be a web app where I have these...
So the tool is called GDB GUI, and it's a web app that lets you debug programs with GDB.
Right.
And so I was ready to read me to tell folks how to get it, how to run it.
So people that are trying to debug things with GDB, maybe they're Python developers, but they're
definitely C developers or Rust developers, some kind of a native language.
So the read me instructions I wrote were, I kind of like struggled with how to tell people
to install this.
Telling them to install pip with pip was not something I was comfortable with because there
are so many dependencies GDB GUI has, and I didn't really want to like break their system.
There was kind of two fears.
Like one, I didn't want to mess their system up.
And two, I didn't know if it would work reliably because there was, maybe they would install
something else and mess it up.
I searched for a while to find something that could get this installed in a better way.
And I'm Pipsy.
Okay.
So yeah, Pipsy like this.
Yeah.
P-I-P-S-I.
Okay.
This is basically exactly what I wanted.
It gives you a single command that creates a virtual environment, installs package there,
and that exposes the binary entry point, which sounds familiar.
It is because that's what PipX's origin is from.
Right.
And in fact, right at the top of the Pipsy read me, it says,
Pipsy is no longer maintained.
You should check out PipX.
Right.
The origin of PipX came from one of the issues in Pipsy where someone,
we were kind of having trouble getting changes merged to Pipsy.
I found it.
I was really excited.
And I started making a bunch of pull requests on it.
And I was having trouble getting things merged.
And basically the maintainers, they were okay with having it in maintenance mode,
but they didn't really want to do active development with it.
And the owner, which was Armin Roedeker, he had sort of unsubscribed from the project.
And wasn't really following it.
And so he was the only person that was able to give more access to let people become maintainers
or so on.
So we were able to add ourselves as maintainers.
So we were kind of stuck with this tool.
We could like, maybe we could fork it.
Maybe we could make a new tool.
Yeah.
So how'd you get from there to PipX?
As I said, I was like, I'm into also TypeScript and the JavaScript community.
And one of the tools they have there is called NPX, which is pretty similar to PipX.
It lets you run CLI apps from Node, who also can have similar challenges because it's an interpreted language.
And so I made PipX to kind of add that capability to Python.
And then I added the ability, since it does kind of like, it makes a virtual environment, it finds the binary in it and it runs it.
It's very similar to installing it.
It's basically installed in a temporary place and runs it versus installing it in a permanent place.
And so I added the install capability on PipX.
I shared it with some of the folks in the issue tracker.
And they were like, this works for me.
Let's go use that.
And this is it.
Yeah.
The momentum continued around it and had a lot of really great contributors work on PipX.
Yeah, that's great.
The GitHub repo says 75 contributors and 5,000 GitHub stars, which is pretty awesome.
Yeah.
I'm really happy with it.
This portion of Talk Python to Me is brought to you by the Python at Scale Summit.
The Python at Scale Summit is a conference to highlight innovative big data solutions for Python developers and enterprises.
You'll learn about trends in the Python big data ecosystem, share stories about implementing solutions,
find out about new innovations, and connect with other data scientists using Python.
The Python at Scale Summit will be a hybrid conference with talks, workshops, and training.
Of course, there will be networking and social events to connect with other Python professionals, too.
Come hear speakers like Matt Rockland from Coiled, Brian Granger from AWS,
and many others from amazing organizations such as NASA, Capital One, and BCG.
Get back together with your peers and learn how they're scaling their computation and data analysis
using Python and the data science stack.
Register at talkpython.fm/python dash at dash scale.
When you visit the link, be sure to use the code TALKPYTHON, all caps, to get 15% off your tickets.
That's code TALKPYTHON at talkpython.fm/python at scale.
The link's in your podcast player's show notes.
Thanks to the Summit for supporting the podcast.
I use it all the time.
I personally really like it, and I'm really glad to see other folks are enjoying it as well.
Yeah, I use it all the time.
It's one of my go-to tools when I want to check out something I know is built with Python as an application,
or I get a new machine.
We can talk about some of the fun stuff to install in a little bit,
but maybe let's first talk about what happens and how do I use PipX?
What's the process?
You do have a nice animated GIF on the GitHub project so people can see what happens,
but maybe walk us through it.
Let's say Glances.
Glances is a fantastic application that you can use,
and if you run it on your machine, it gives you this super rich terminal-based real-time view into your servers.
It's much, much better than top or something like that.
It also has a web view and whatnot.
So that's a thing that people might not care about Python for,
but it happens to be written in Python, so it's a perfect thing to PipX install.
Exactly.
Yeah, so talk us through, if I have PipX install Glances, what happens?
Yeah, sure.
So the first thing is PipX will try to determine which package you're trying to install.
So you can give it just a name Glances, or you can give it basically any pip specifier,
any kind of, it can be a Git repository, it can be a wheel, anything pip can install, PipX can install.
So first it will make sure that it's a valid package specification.
Then it will create a virtual environment in this directory that PipX manages.
So it'll make a virtual environment with the name of the package.
It'll make a Glances virtual environment.
Then it will do some introspection on the, that it will install Glances into the virtual environment.
So now we have a virtual environment with Glances installed,
but it's not accessible anywhere other than inside that virtual environment.
And so the next thing it does is it does some introspection on the virtual environment to say like,
what binaries do we have available?
And so it would be expecting Glances to be available.
And it will then take, it'll find the path to the Glances binary and create a symlink into a directory on your path,
on your, on your shell's path.
So that when you run that command, it's available.
Right.
So for example, you need to have, in your little example here was home slash csmith slash dot local slash bin.
And then that's the folder where all the symlink stuff gets linked over.
You can also do those with entry points, right?
It'll find the entry points and make them available.
Yeah.
So these are cons.
These are, these are entry points.
These are the console scripts.
Okay.
So that leads me to a question out in the audience from Ratul.
Ratul says, this looks great.
Not sure if I missed it, but how do you get your built Python app to be pipx installable?
So you said it has to be pip installable, but then I think the other point here,
you would have to expose some functionality in a way, and that could be entry points, right?
Yeah.
So pretty much that is the, essentially the only way is this, is the console script entry point.
So you can look this up.
It's a kind of well-defined part of the packaging specifications, but you can define a function
that you want to call from a console script entry point.
Yeah.
So in your setup, you would say something like set up tools dot setup entry points equals,
and then you give it a list of a command and then basically a module colon function, right?
So here's this example that I'll link to in the show notes is, is hello world equals hello
world, which is the module name colon say hi, which is a function in hello world.
And once you pip install that into a virtual environment, you could just type hello world
and it would do whatever it does for that function.
But what you're saying is if you install with pip X, it finds these and creates basically
binaries that the system can see that it thinks it can run called hello world, for example.
Yeah.
When you pip install something that has a console script, it makes this like a shell script that
calls that function for you.
And so these shell scripts just get sim linked out onto your path by pip X.
Got it.
Yeah.
So it's basically doing the install.
It's creating the virtual environment automatically behind the scenes.
It's installing, doing basically pip install on the package, but that drags in all of the
dependencies.
But the important thing is every one of these commands, or I guess the thing you pip X install,
it can have multiple commands as part of it.
It gets its own virtual environment that's isolated, not just from the rest of the system,
but all the other pip X things as well.
So they're versioned and they live independently, right?
Exactly.
Yeah.
You can have more than one console script too.
A lot of times package will have, you know, two or three, four console script entry points
and pip X will find all those.
Nice.
Yeah.
One that comes to mind is pi jokes.
Are you familiar with pi jokes?
Yeah.
I've heard you guys talk about that on the podcast before.
Yeah.
Pi jokes is a good one.
So this one has entry points and I always get this through pip X.
I just, you know, pip X install pi jokes and you end up with a bunch of, who'd they say
pip X, right?
And then you can run pi joke or pi jokes.
And even as a program API and you get really deep jokes.
Like why did the programmer quit their job?
Because they didn't get a raise.
A raise is in like lists.
But you know, it's those types of things, right?
You don't necessarily care that pi joke is written in Python.
I mean, the name would maybe make you think it should be, but right.
You just want to have a command that you can type something and get a funny programmer joke
out of it.
Right.
But maybe we could touch on some of the other things that are more useful than pi joke.
Like one you mentioned was the GDB GUI.
I gave a shout out to glances because glances, I said, is fantastic.
I use glances all the time.
It just happens to be written in Python, but I just want it on my server.
Maybe another one that pointed out was HTTP pi.
HTTP pi, HTTP IE.
Do you use this one?
I have not used it too much, but I would love to find an opportunity to use it.
Prefer it over things like curl.
Yeah.
I love HTTP pi.
It works just like curl in a lot of ways, but the results that it gives you, it gives you
syntax highlighting, easy ability to say, just show me the headers and the response, the
response headers and stuff that came back and cookies.
And it, you know, does highlighting on those.
It's really nice.
So just pipx install HTTP pi, and then you get HTTP as a command and HTTPS.
Here's another one with two entry points, right?
So if you just want to say HTTP, you know, 127.0.0.1, you don't have to say HTTP colon slash
slash server name.
You can just say the command, either HTTP or HTTPS, and it'll, it'll do it.
It's just a little bit shorter.
Right.
So this one, big fan.
But what was surprising to me about this is, you know, this is backed by a company, right?
There's like a whole bigger organization behind HTTP pi than I realized, I believe.
So I was impressed with their website.
It was a lot more polished than a lot of other open source projects.
So I'm not surprised to hear that they're funded or they're part of a company.
Yeah, exactly.
At the bottom, it says like job, there's a whole job section.
There's apparently four jobs for HTTP pi, which is incredible.
At the same time, it's a fantastic tool.
Yeah.
So, you know, good on them.
Let's see.
Maybe some of the other ones.
I know we had a little bit of list of stuff that could be fun.
Pi installer, pi to app.
Let's see.
Pi installer, pi to app, Cython.
A lot of the package management stuff.
Poetry, pipenv.
Yeah.
Anything else you want to give a shout out to?
I've got one I want to use as well, but go ahead and do yours.
Another program I made, I guess I'll plug my own, one of my other projects, it's called
Term Pair.
So this is actually kind of a web app.
It lets you share your terminal session through the web.
But it does it by encrypting all the output and input from your terminal.
And so basically you run this command term pair share, and then it will start sharing through
this server.
And then you can either, you can control it from the web app or you can control it from
the terminal.
And the process running in the terminal is a Python app.
And then, of course, the web app is JavaScript React.
Yeah.
How interesting.
Does it give you your normal shell or is it like a bare bash or Z shell or something?
By default, it uses...
Like if I do a super configuration of my shell, make it like all blinged out, and then I run
this, do I get the same crazy configuration or is it a simpler version?
No, it's the exact same thing.
It'll just run whatever shell, whatever the shell environment variable is that you're running.
It'll just, that's the default command.
You can run any command you want.
If you want to run Python, you can run Python.
It'll share your Python session.
You can run anything really.
But if you run a shell, that's the most familiar thing, I think, for sharing.
Sure.
Interesting.
It'll share basically any CLI thing, huh?
It spawns a PTY process.
And then any output or input just gets written and behaves like any other terminal would.
So you can do stuff like, you know, this is HTOP where you're interacting with it.
And it's kind of like rewriting lines to the screen.
And it's able to handle all that.
It might be a nice way to help people who are like, you know, I'm stuck.
I can't get this to work.
You're in an email exchange or a Zoom meeting or something.
You know, run this and give me the link.
And I'll just, let me just ask your system a question real quick and see if it does the same.
You got to have a lot of trust to give this over to people though, right?
Yeah.
You know, I made it because it seemed really fun.
It was a challenge.
It seemed fun.
Practically speaking, yeah, I don't know how often it's used.
You'd have to totally trust somebody to not.
I mean, they have full control over your computer.
Sure.
It's not that different than going to a Zoom meeting and say, allow so-and-so to share,
to control my mouse and keyboard or team viewers or something like that.
Yeah, that's true.
Yeah.
But still pretty neat.
I don't know.
It's just so more visceral.
It's right there.
You could just RMRF it right there.
Yeah.
There's another one I want to pull up here.
This one, PLS.
Do you use PLS?
Any?
Yeah, I've tried it out.
It's pretty cool.
I like that you can do so many different things.
I like how easy it is to develop applications in Python, where you can just kind of make whatever
customizations and hack things up really quickly.
Absolutely.
So PLS, it's a little hard probably to see over the screen share.
It's a replacement for LS.
And I know there are many replacements for LS, but this one is cool because it's a developer-friendly
one.
And so when you interact with it, it will use a lot of different things.
For example, it'll show icons for Python logos next to .py files, JavaScript logos next to
JS files, and so on.
But it will also use git ignore files to decide what shows up in the basic view.
It'll show you the git status of the file.
When you do a PLS --details, you'll see which files in that listing are modified
in git, according to git, and so on.
So there's just a ton of fun stuff here that you can check out.
I definitely think it's neat.
Here's some examples of some of the colors.
For example, poetry.lock, because it's git ignored, but still important.
It shows up, but it's a very faint color, whereas other files show up with regular colors.
So this one is another one that's good to pipx install, right?
Because you just need it once for your computer.
Yeah, I love those colors too.
Great color scheme.
Yeah, yeah, absolutely.
And apparently you can build little plugins and stuff for it, I think, in Python.
I haven't tried to do that.
I've just tried to use it as a user.
But yeah, that one's a fun one.
For a while, I replaced LS with it.
That wasn't a super idea, because it behaves weirdly.
If you try to LS something and it doesn't exist, you get a traceback exception instead of just doesn't exist or nothing.
It's not perfect, but as a thing that you have hanging around, it's definitely quite neat.
Yeah, replacing system utilities can get kind of risky.
Yeah, you just got to know what you're doing.
I'm willing for this to mildly break stuff.
But if you make it like you said that one time you couldn't turn on your computer, then you're in a bad spot.
Or if you could at least get back and edit your profile, your shell profile, and turn those back to normal, then you're probably okay.
Yeah.
Well, maybe real quickly, you could give us just if there's any interesting internal, there's some interesting tools or stuff that happens behind the scenes with PipX.
Give us a look inside real quick, and then maybe we could wrap things up.
Any interesting internals of PipX?
Let's see.
Yeah, yeah.
Like notable libraries that it uses or something that's really valuable in there.
I was poking around the PyProject.tabble, and there's like argcomplete.
Sounded interesting to me.
And then a user path is new to me as well.
Okay, yeah, yeah.
Sure.
So argcomplete, I'm a huge fan of.
Argcomplete is a package that, so if you use argparse, which is the standard library's argument parsing package,
a lot of times you'll want to have like tab completion and tab completion can be really hard to write.
And so argcomplete gives you a Python API to tell it how tab completion should work.
And so in PipX's case, if you're going to do something like PipX, like uninstall a package, you have to give a name of a package that's been installed.
And so with argcomplete, you can say like PipX uninstall tab, and then argcomplete, you give argcomplete a list or like a way to get a list of packages that can be uninstalled.
And then it gives you that tab completion just like you'd expect.
And it also does it across shells.
So like writing it for just bash is enough to do, but then you also have to write like different completions for fish or something like that.
And so argcomplete lets you not think about that and just use your argparse as you normally would with just like a couple extra arguments.
And then boom, you have tab completion.
Right.
Yeah.
There's a whole section where you talk about how to install completion in here for the shells.
So, you know, do you do that for, if you just type PipX space completions, it'll tell you how to do that, right?
Right.
And argcomplete's useful for, I mean, I actually added it for Knox.
I'm a big fan of the tool Knox, which is also PipX installable and Knox.
A lot of times you want to, there's only a lot of sessions.
You run sessions in Knox and there's a whole bunch of them.
And so having a tab completion on that was a feature I really wanted.
And I think, I think that's where I first found out about argcomplete.
And then I started adding it to other projects after I found out how easy it was to use.
Right.
You're like, this is not that hard.
I want this.
Yeah.
Cool.
The other thing that people need to remember to do is to run PipX ensure path, right?
Right.
Because you talked about, we talked about that .local slash bin in your user profile, at least on macOS.
I don't know if that's where it goes.
It might go somewhere else in Windows.
But you want to make sure that's in your path.
So that'll basically modify whatever your active shell profile is to make sure it's in your path, right?
That's right.
Yeah.
And you can also modify where that binary directory is with an environment variable if you want.
Okay.
How well does this work on Windows as well?
Does it work there?
Is it like PowerShell friendly and stuff like that?
So it does work on Windows.
I know that one of the contributors is one of the maintainers is a Windows user.
And I don't see a flood of Windows issues coming in about this doesn't work on Windows.
So it should work on Windows.
Yeah.
Perfect.
Okay.
And then it can upgrade itself.
If you do pip upgrade like --user or something like that.
It doesn't install itself.
I'm considering making a new installer where pipX installs itself with pipX.
I'm not sure I'm going to land that.
Right now we install pipX with pip.
And so you would just upgrade it normally with like pip upgrade pipX.
Sure.
Okay.
Or it's pip install dash user.
Sorry.
Another thing that I like about pipX is you can just say pipX.
What is it?
Upgrade all.
Yeah.
Or there's a command to just upgrade.
You know what?
Give me a new version of all my libraries.
Which comes back to similar with apt.
Similar to homebrew, right?
There's a brew update and outdated and just show me the stuff that could be updated.
And then we'll just do it.
Same with Chocolaty.
Just to keep the tools used fresh.
It's really nice.
Yeah.
It kind of goes back to like, I have this program.
I don't really care about that.
It's written in Python.
I just want this thing to work.
I want the newest version of it and just kind of make it happen.
Right.
And but if we reverse that and we're talking to Python developers, as most people listening
are, you can empower people to deliver their applications to end users in a way that is
much, much, much simpler if they're not Python people, right?
Yeah.
If they can get PipX on their machine, then getting the rest of their stuff is basically
done, right?
That's a great point.
Yeah.
I mean, the distribution story gets a lot easier for your users.
If you're a developer and you want to get this in people's hands, having them use PipX
is going to cause them less headaches and it's going to cause you less headaches because it's
going to be more predictable environment to install in.
Because PipX kind of lives in the center of a few things.
Like you have wheels, which are pre-built packages specific to your operating system.
And you have pip and PipX and virtual environments.
And PipX kind of marries them all together in a way where it takes the pre-built, doesn't
have to rebuild it on the user's computer.
It takes this pre-built thing that works.
It puts it in a place that's not going to disturb anything.
It's not going to get disturbed either.
And then it makes it accessible to the end user.
And they don't have to think about any of those pieces to get it on their computer.
Yeah.
So maybe one of the biggest takeaways is if you're trying to deliver Python applications
to people, here's a really good option.
If some kind of CLI starter is the way to go, right?
I guess if you want, here's how you drag it over to your applications folder and put it in
your doc.
Maybe that's not the right thing.
But you know, for a lot of the type of stuff people are building with Python, it's a great
way to get it to end users and keep it up to date.
One other thing I'll call out is pipx run.
Yes.
Yeah.
We've talked about install the whole time.
But yeah, pipx run is maybe even better for certain things.
Yeah.
So pipx run will make sure you have a recent version of the tool you're trying to use.
So if you want to run some kind of a bootstrap program or some kind of like cookie cutter
where you create a new project or something like that, then you'd want it to run with the
recent version.
pipx run will just kind of make it happen for you.
Right.
So one of your commands might be, well, first, you're going to set up a virtual environment
and then you're going to pip install cookie cutter.
Then you're going to run cookie cutter this thing.
Right.
Well, maybe the step is if you already have pipx, assuming this is a thing that's accessible,
pipx sort of install run cookie cutter and you give it that command.
Nobody needs or wants cookie cutter after that.
They just need cookie cutter to run the skeleton generator for their project.
And then their project is kind of free from cookie cutter because you can't update your
project afterwards anyway.
Right.
That's probably a good mental model to have.
Yeah.
And that's how the JavaScript world uses it.
It's kind of like, it's one of the really popular ways.
And you'll see the NPX, you know, create React app is a way to start React apps with,
with the latest version of that cookie cutter type thing.
And so I would love to see more adoption on, on that side in the Python world.
Yeah, absolutely.
Another one, I guess, let's just real quick, maybe give a shout out to this is the Node.js
thing that just got added.
Isn't there a way that just came out for installing Node.js as a dependency, not just the bindings?
I feel like there just was.
Yeah.
I saw something about this.
Yeah.
Actually, I think we just covered it on Python bytes, but I wasn't the one who brought it up.
So I don't totally remember.
Let's see.
There you go.
Node.js dash bin.
That's it.
Gina Houska covered it.
And yeah, there it is.
Node.js dash bin.
So if you've got something that needs to have the Node tools around or, or CLI stuff,
you could, you could just pip install Node.js dash bin.
So I guess you could also pip and X install Node.js dash bin.
Yeah.
Maybe if it's a, if it's an entry point, then for sure.
Yeah.
I haven't thought enough about it, so maybe it doesn't quite fit in there, but it's an interesting,
interesting development.
All right, Chad.
Well, I think we're probably out of time for talking about pipX.
Let's maybe wrap things up.
Any final thoughts or anything you want to add to this before we get to the final two
questions?
No.
Thanks for having me on and sharing some discussion on pipX.
Yeah, absolutely.
It's a great tool.
All right.
Final two questions.
If you're going to write some Python code, if you're going to work on pipX or your terminal
replicator or whatever you're doing, what editor are you using these days?
I use VS Code.
Yeah.
It sounds like Meta is pretty standardized on that.
Is that right?
That's our company-wide editor.
Do a lot of work on writing extensions for it and making it work for developers in Meta.
Yeah.
Cool.
And then we've talked about a ton of PyPI packages, but one you want to give a particular
shout out to?
Yeah.
So this one is not pipX installable, but I think it's super cool.
MK docstrings.
And this is a way to generate documentation from your code.
I think it's similar to Sphinx.
I haven't really used Sphinx too much, but I find MK docstring is really user-friendly.
It's all marked down.
And I think it's really like a good looking UI that it generates for you.
I think it's really easy to use and it gives you a nice end result too.
Cool.
Fantastic.
Good recommendation.
All right.
Final call to action.
People want to play with PipX, develop Python apps that can be installed through PipX and
so on.
What do they do?
How do they get started?
How do they get started developing apps for PipX?
So you can use any of those tools to get a piproject.toml file and have a publishable package and make
sure you have a console script entry point.
Really, all you have to do is have a console script entry point for your package and then
PipX will take care of it for you.
Yeah.
It's worked with everything that I've tried it with.
So it seems pretty solid.
Great.
Yeah.
Awesome.
All right.
Well, thanks again for being here and for working on PipX.
It's a great project.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
Mergify is an amazing tool to make you and your team way more productive with GitHub.
It's all about leveling up your pull requests.
With automatic merges, auto updates, PRQ prioritization, and backports, you'll tame your
PRs once and for all.
Get started at talkpython.fm/mergeify.
Sign up for the Python at Scale conference to connect with your data science colleagues
and learn about trends in the Python big data ecosystem.
Share stories about implementing solutions and find out about innovations in our space.
Visit talkpython.fm/python dash at dash scale.
That's talkpython.fm/python at scale.
And use code talkpython to get 15% off your ticket.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.