Have you ever had trouble installing a package you wanted to use in your Python app?
Likely it contained some odd dependency, required a compilation step,
maybe even using an uncommon compiler like Fortran?
Did you try this on Windows?
How many times have you seen cannotfindvcvarsall.bat before you have to take a walk?
If this sounds familiar, you might want to check out the Conda Package Manager,
Anaconda, the distribution, Conda Forge, and Conda Build.
Together, these dramatically lower the bar for installing packages across all the platforms.
This week, you'll meet Phil Ellison, Kale Franz, and Michael Sarahan,
who all work on various parts of this ecosystem.
This is Talk Python to Me, episode 94, recorded December 14, 2016.
Welcome to Talk Python to Me, a weekly podcast on Python,
the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm,
and follow the show on Twitter via at Talk Python.
This episode is brought to you by MongoDB and Continuum Analytics.
Thank them both for supporting the show by checking out what they have to offer during their segments.
Kale, Michael, Phil, welcome to Talk Python, guys.
It's great to have you here.
Thanks, Michael.
Thank you.
Great to be here.
I'm looking forward to talking about Conda.
It's going to be really fun.
There's a whole ecosystem growing up around it,
and I think it's a little bit underappreciated just from the people I talk to,
and so I really want to spread the word about how cool Conda is and what you can do with it.
So we'll get to all that, but let's start with your guys' story.
How have you gotten into programming?
Since there's three of you, let's kind of keep it a little bit short,
but just, Kale, maybe how do you get into programming in Python?
30 seconds.
Yeah.
In grad school, I was writing a lot of MATLAB code, and then MATLAB is proprietary,
and this thing called NumPy came along and started using NumPy, and it kind of grew from there.
Oh, that's really cool.
Now you're at the very center of the nucleus of NumPy and all that kind of stuff.
That's great.
Michael, how about you?
Yeah, I started out with a web program to show my photos to my parents and family,
and then grew into science stuff when I went to grad school, much like Kale.
So, yeah.
Nice.
What did you study in grad school?
Electron microscopy.
Okay, wow.
Very cool.
Lots of very small things, huh?
Yeah.
Was that like image recognition and things like this?
Yeah, and also spectral processing, so all kinds of fun signal processing and unsupervised learning.
Oh, okay.
Very cool.
Phil, how about you?
So, I started pretty young.
I started with Visual Basic when I was about 14, and then at university, I did quite a bit of Maple,
which is kind of a mathematical language pretty similar to SimPy,
and then picked up Python when I was in my gap year in France.
I just loved the open source community, loved the scientific Python space, and went from there.
Yeah, that's excellent.
So, you were kind of bumming around Europe, and most people just hang out and chill,
and you picked up Python.
Very cool.
Yeah.
Awesome.
Okay, so let's get into Conda first, and then we can get into Conda Build, Conda Forge,
and the various things around it.
So, Kale, tell us, what is Conda?
Conda's a package manager.
Install software and use software.
It does a lot more than just manage packages.
It manages environments.
So, there's Conda inv, or there's an environment manager and the concept of environments, much like Python virtual inv, except it's system level, and it's Python agnostic, the environment part.
Oh, it's language agnostic.
So, you can have environments for, I mean, if you want to build Ruby with it, or whatever types of environments you want, completely supported.
So, yeah, it's package manager.
Very nice.
So, it's kind of like pip in some of its role, but it does more, right?
In some ways it does more.
In some ways it does less.
So, Conda and the Conda ecosystem is not the canonical source of truth for Python packages.
That's PyPI, and we don't install packages directly from PyPI.
That's PIP's job.
We don't pretend to.
But we're much more like, in some ways, more like a system package manager.
So, more like apt-get or yum or something like that.
A lot of times with a system manager you'll install Python or you'll install some of your core dependencies.
The harder things that pip will invoke a compiler for and things will crash or things like that.
I have wheels help now, but pip still can't install Python.
So, things that are a little bit lower level is where Conda really excels at.
And then, so, yeah, that's the tradeoff in capabilities, I guess.
Sure.
And let's see if I got the origins correctly.
I'll tell you what I think and then you tell me whether I'm right or wrong.
So, I feel like Conda came from sort of two places.
It feels like it came from you guys wanted to make it easier for data scientists and people, more correctly,
people working with the data science and scientific tools like NumPy and so on to actually start working with them.
Because they often had really freaky builds.
So, like they might depend on some sort of Fortran thing.
And so, in order to pip install, you have to have like a Fortran compiler.
A Fortran compiler.
Yeah, yeah.
Which, I mean, we're already battling with where is vcvars.bat again on Windows?
And now you're talking about Fortran compilers?
Come on.
So, is that sort of where it came from?
And it had to manage all these different things like Fortran, for example?
Yeah, that was the genesis.
And Conda came about about the same time as wheels came about.
So, there's a little bit of two different approaches.
But they've sort of diverged into really pip and wheels and things being Python specific.
And these source of truth for Python if there's not a more downstream distributor.
Whereas Conda, we do take care of all the hard parts.
So, NumPy and SciPy and all those dependencies.
And then Python and all the runtimes and stuff like that.
Yeah.
And one of the big differences is that you guys pre-build the binary pieces that we might need, right?
Yeah, that's correct.
So, a lot of times people ship to production and absolutely do not want compilers on their production systems.
And so, we do ship binaries.
Yeah, I find that to be really excellent.
Because, you know, like if I go and get SQLAlchemy or I think PyMongo even, some of these things that have C speedups at various places, often for like deserialization and serialization steps.
And if I don't have the right setup, you know, maybe it's not going to work.
Especially if I'm on Windows, for some reason that gets a little harder to do and gets neglected often.
And so, it makes it like doubly hard, right?
Sure.
And those things you don't have to worry about if I Conda install it, right?
Because it's already been compiled somewhere else by you guys.
Not only do you not have to worry about that, but you can Conda install Postgres or all of your other general dependencies.
It's not just Python.
We have a huge R ecosystem.
There's plenty of other ecosystems that people are, language interpreter ecosystems that people are building up around.
Okay.
And I guess another point about Conda versus a system package manager like YAM or apt-get is for your application code, you rarely want to be running the system Python.
You always want to have an application-specific Python.
And the OS package managers don't make that as easy.
You basically have to make your own RPMs or something like that.
Conda allows these isolated environments.
Yeah, it absolutely does.
That's very cool.
Very cool.
Okay.
So, how does Conda relate to Anaconda?
Sure.
Anaconda is a distribution.
There's an Anaconda distribution that is a set of packages that we ship about every quarter.
That is the easy way for scientists and engineers, data scientists, PhD students all over the world, to install most of the core Python packages that they'll need.
To do that, and the package manager part then is Conda.
And so you get Conda, and then when you need to install other packages from any of our repositories or anaconda.org or anything like that,
Conda is the command to extend what you install with the Anaconda distribution.
Okay, so Anaconda is like all that stuff pre-packaged, pre-compiled, like the major tools you want.
And Conda is the package manager for it.
Nice.
Phil, how about Conda Forge?
Where does Conda Forge relate to all this?
So, if you see Anaconda as a nice bundled set of packages to install Python and all of its dependencies,
then Conda Forge is essentially doing the same thing,
except Anaconda is managed by Continuum, and Conda Forge is a community effort.
to kind of collaboratively to package this stuff.
There are so many packages out there, right?
I mean, just like you guys said, Conda is more than just Python.
But just in Python, there's over 90,000 packages on PyPI, which is crazy, right?
So, you probably can't manage all of that yourself, right?
No.
And so Conda Forge is to help crowdsource that, open source that a little bit.
Yeah, exactly.
It's not reasonable for us to expect Continuum to package all of this stuff.
It just simply doesn't scale in that way.
We needed a community effort to package some of the things that Continuum aren't necessarily ever going to package.
At the end of the day, they're a business, and they're there to supply their customers.
And that doesn't necessarily cover everybody who has various bespoke packages that need to be shipped.
Yeah, absolutely.
There's probably a very quickly small niche tale that sort of develops, right?
There's probably 500 or 1,000 packages that are super important, and then it becomes really niche quickly after that, right?
Absolutely.
That's where Conda Forge started, really.
I'm the author of several niche packages, which are extremely powerful for the people that it's targeting.
But by no means would you expect that to be packaged by a company who are there, ultimately, to sell a product to their customers.
That product may be freely available, but we don't have, as a community, we don't have control of what's packaged and how it's packaged.
Sure.
Yeah, that makes a lot of sense.
So I guess I didn't really ask, what is Conda Forge?
Maybe give people a quick definition so they know what we're talking about.
Okay.
So Conda Forge, in the same way that Anaconda is a bundle of pre-compiled Conda packages, Conda Forge is exactly the same thing.
It's a channel that you can enable using the Conda package manager to install all of your favorite tools.
And if your tools aren't available on that channel, then it's a community effort, and you're welcome to contribute your package to be bundled into the Conda Forge community and make it widely available to Conda users.
Right.
Okay.
Yeah, we'll definitely dig into that more and how you can do that in a little bit, but that's great.
And so in order to deliver things in a binary form, basically compiled for Windows, compiled for Linux, compiled for macOS, and things like that, you guys probably have some pretty interesting build infrastructure.
Michael, do you want to talk about that?
Oh, sure.
Yeah.
So we have a lot of different build machines.
And so one of the main advances that Conda Forge has done is to take advantage of many of the free continuous integration services that are on the web.
And so Phil figured out really, really clever ways to get around the different limits that those CIs present.
So he thought, oh, well, you know, it's not going to work to build an entire repository of recipes.
So can I instead break up the one repository into one recipe per repository?
And that was a really clever workaround that made it possible to use those CIs as infrastructure.
So that's part of it.
At Continua, we just have kind of a standard build system where we try to maintain compatibility with older frameworks because we support customers with old CentOS 5 and RHEL 5 systems.
But other than that, it's the same kind of idea.
Okay.
And you build it for, I can see how you would set up CI on Windows pretty easily.
I see how you set up on Linux really easily.
What about Mac?
So Mac is...
It's got to be a story behind that laugh, right?
Well, it's a little bit more awkward.
And the main reason why it's awkward is just Apple licensing.
They don't let you run virtual machines on anything but Apple hardware.
And so the number of people who are offering particularly free services with Apple builds is much more limited.
And that said, you can get it on both CircleCI and TravisCI.
And so we use TravisCI for Condo Forges Mac builds.
Okay.
Yeah.
I mean, there are a few places.
Like there's a place called Mac Mini Colo where you can get a bunch of Mac minis and stick them in some data center and they'll like run them for you.
But yeah, it definitely makes it harder.
But you guys found some kind of cloud service that you can use.
You don't have like a closet full of Macs?
At Continuum, we do have a closet full of Macs.
Okay.
Great.
But I really think this binary distribution thing is really excellent because certainly when you're getting started, it's frustrating to deal with the single compile, the single install.
So just knowing that it's always going to work is great.
But also the speed, right?
You can install stuff much quicker because you don't have to wait on a build.
Yes, certainly.
So if you're a Linux nerd, then it's kind of Gintu versus Ubuntu, right?
Yeah.
Yeah, yeah.
Very nice.
So you have a lot of different places where code is running.
We talked about the three major OSs.
Do you have compatibility for others?
You talked about older systems, for example.
How do you keep that all straight?
Well, that's a really hard thing, actually.
So the way that things are compatible varies by platform.
And so for Mac, we kind of have to target an older platform, and then it's forward compatible.
Windows is a weird story because on Windows, the Python version is pretty strongly tied to a particular version of Visual C++.
And so that's limiting in terms of what kind of code people can actually compile.
What version do you know?
Sure.
Yeah.
So Python 2.7 requires Visual Studio 2008.
And that's just kind of a custom because that's what the upstream Python.org build is.
And so in order to maintain binary compatibility, it's a good idea for everybody to keep that matchup.
But as a result of that, people can't really build C++11 software for Python 2.7 without mixing these runtimes.
And when you mix runtimes, it's just kind of it might work.
It might not.
You're kind of asking for instability.
Yeah.
No kidding.
It is too bad because C++ has actually had a bit of a renaissance, right?
Absolutely.
And 2008 misses.
That renaissance, that's too old for it.
Okay.
Interesting.
Can you, any of you guys want to jump in on this?
Talk about some of the challenges for community packaging.
Like, if I'm getting binary code delivered to me, how do I trust it?
Is that really different than trusting the source coming out of PyPI?
Sure.
I'll chime in a little bit.
I would say it's not any different from getting it from PyPI, except that if you get it from PyPI, you can at least inspect the source.
Whereas if you've got a binary blob, you have to have a different level of trust.
I think there's one extra level to that because PyPI, it is the original package maintainer that's uploading the package to PyPI, right?
We're taking from PyPI and we're downstream from that.
So there is an extra level of people in between.
On top of that, anybody can upload anything, any package they want to, to Anaconda.org.
It's up to the user to decide whether they want to use it or not.
And so there are some challenges there.
There's also a question of reproducibility in the sense that if you're getting the source, you can compile it anywhere, right?
But if you're getting a binary and you want to go and change your machine, then you're kind of, you're missing out on the ability to rerun that compile step where you choose.
Yeah.
So if you get a new machine, you're always going to have to go back to install via Conda.
You can't just copy the files over and regenerate it or something.
If you're on different architectures, for sure, you need to go and refetch the appropriate artifact for your hardware.
Yeah.
Okay.
That said, do you guys do, you know, I had Travis Oliphant on one of the earlier shows and I feel like he said that you guys did some verification that at least the stuff that ships with Anaconda,
mixes well together that one package that depends on another, you know, that those are compatible versions.
Is that right?
Right.
We do a lot of that.
And so we have our own kind of automated scripts that test our whole system together.
And then Conda Forge sort of does that in a more distributed way to say when they build a package, they run the test suite.
We also do that.
We run a few other consistency checks.
But those are the kinds of things that let us make sure that everything is playing well together.
I'd add there that the Anaconda distribution is extensively, we release it about quarterly and it's extensively tested manually.
We have a whole QA team that goes through that and make sure that each package works with, or each of the packages, however many that make up the full distribution work together.
So yeah, there's a lot of extra testing that goes into the distribution.
Yeah, I think that's really great.
I think that's one of the big values, not just that you don't have to be able to compile stuff to install it, but that it's taken as a whole somewhat.
You can trust it rather than here's a hundred little pieces.
Individually, they're probably fine.
How are they as a put together, right?
Yeah, the downside of that is when you install the Anaconda district, Conda install Anaconda, you're explicitly pinning all of your versions or all of your packages to a specific version.
And then when you want to update everything, people get confused about, I was looking for the most recent version of Jupyter and I said update all.
Why didn't I get the most recent version of Jupyter?
So there's a little bit of a downside.
That is a bit of a downside, I guess.
I did notice that.
One of the things I was playing around with was trying to use Conda for my web apps.
I noticed some of the web frameworks were farther out of date with what I got out of there than I guess I'd like.
Can you talk about that?
Whoever has the best info, I guess, on how do we like as things evolve?
You know, so suppose I've got some package put into Conda Forge.
How does the versioning on PyPI map into Conda Forge?
Yeah, I'll try to shoot that.
It's a manual process to update the recipe that creates the Conda package.
And so someone has to update the recipe on the staged recipes or on the feedstock on Conda Forge.
And then it's built out automatically by the CIs, which is great.
The CIs save you a lot of effort.
At Continuum, we don't have our CIs quite working yet.
And so it's really a much more manual process to edit the recipe and then build out each of the different packages.
With that level of effort, it's just a matter of first noticing that there is a new version available and then doing the work to package it up.
Sure.
In the defense of Anaconda versus Conda Forge here, there is clearly a huge overlap between what Anaconda does and what Conda Forge does.
From someone who's not part of the Anaconda team, I just want to say how much of a great job the Anaconda team actually do in providing a really coherent, well put together set of packages that you can trust, you can rely on.
They're stable.
And really, I guess that's the big selling point of Anaconda.
And Conda Forge really isn't trying to be in that space at all.
What it wants to be is the kind of the leaner, faster moving community effort.
But there is no chance that Conda Forge can be as well curated.
It can't provide the indemnity that you get from Anaconda.
As a distribution, Anaconda is just an amazing resource to have in the community.
Yeah, and it ships quarterly, so it's probably, you know, if you're willing to wait an extra month, you'll be on the new version of a lot of things anyway.
If I'm an author of a popular open source package that's either in Anaconda or Conda Forge, what can I do to make sure that the latest possible version is there, given that I have to accept the release cycles and stuff?
But what do I do?
Is there a place I talk to you guys, or what's the story?
We both have places to submit pull requests to recipes.
And so for the internal, for Anaconda, it's a recipe or a repository called Anaconda Recipes.
And then for Conda Forge, it's going to be the feedstock for whatever you want to improve.
If you want to add it, that's a staged recipes PR.
Absolutely.
Okay, so let's maybe talk about the recipes and feedstocks and stuff a little bit.
I have one more comment that I might have given the wrong impression about the distribution shipping quarterly.
The distribution is like one installer, one big meta package that has all kinds of stuff in it.
We're constantly updating.
I mean, Conda Forge too, but our source, our default repositories, we're updating all the time.
And you don't have to wait for the quarter to come around to get more recent packages most of the time.
Oh, yeah, yeah.
Okay.
It's just the Anaconda distribution and the big Anaconda meta package is updated once a quarter.
Those are the packages that get all the extra QA and making sure that they all put together and stuff.
I see what you mean.
So like the DMG I got from my Mac, that thing is updated quarterly.
But you're right.
When I run a little green circle thing, the sort of overall environmental manager, that thing, I can go and update stuff as they come.
I remember doing that quite more frequently.
That's cool.
Let me take just a moment and tell you about a sponsor of this episode.
Anaconda Con 2017 is the first conference for open data science leaders around the world
and the definitive gathering place for the Anaconda crew.
Whether you are a new or longstanding member of the community focused on business or technology,
Anaconda Con will help you conquer your biggest data science challenges.
Data science is a team sport.
That's why they're offering you two tickets for the price of one to Anaconda Con 17 starting now until January 16th.
Register today at talkpython.fm/acon to take advantage of the spectacular savings.
You'll get two tickets for the price of one,
and you'll have the lovely tech-oriented city of Austin, Texas to share with your friend and all the top data scientists.
Yeah.
So let's talk about these recipes just a little bit.
So let's focus on Condo Forge for a minute.
If you go there, you can go to github.com/condo-forge, I think.
And you've got, yeah, you've got a couple of repos.
One of them is feedstocks, and that's where the accepted, those are the accepted sources that you guys pull from, right, to build packages?
Right.
We have a repo which holds, using Git submodules, every single individual feedstock repo that lives in Condo Forge.
So the feedstock is the place where the recipe is stored canonically, and that has continuous integration enabled.
So whenever we make changes to that recipe, it goes away, and it builds it each time and makes that artifact available on the Condo Forge channel.
Okay.
Maybe tell us what is a recipe.
You've got a couple of pieces that make that up, right?
Sure.
Mike, do you want to talk about recipes?
Yeah.
A recipe is a YAML file, for one thing, and it's just kind of a way of expressing a standard of how you tell Condo Build or any other program that interprets that YAML file.
Where you go to build the source, what are your build options, what are the instructions that you carry out to actually do the source,
and then one thing that we're adding in is how do you package the source after you've built it,
because some of the time you want to package different parts of what you've built into different packages.
I see.
That makes sense.
So if basically we go to GitHub and there's a link to a submodule that gets pulled in for each one of these,
if it's somewhere else other than Git, like Subversion, is it still possible to stick it in there,
or does it have to be copied over to a GitHub repo or something?
Condo Forge is based around the GitHub stuff, but there's no intrinsic limit to Condo Build as to where a recipe has to come from.
Right.
Okay.
Well, let's talk quickly about Condo Build.
Michael, you're also in charge of that, right, or working closely with that?
Yes.
So what's the story there?
Like, if I want to take a package and build it with Condo Build, I've got to put together the recipe for it to work.
I've got to obviously have the sources.
And then I get it set up and I give it to you guys and you ship it off to CI on various platforms to build out the various versions or what happens?
Yeah.
Condo Build is really just a lot of orchestration of environment setup.
And so building up a build environment is pretty hard.
There's a lot of different pieces that go into that.
And so in previous jobs as a software developer, setting up your workstation takes a day or two.
So what Condo Build is really for is abstracting that away and taking advantage of Condo environments to make that setup be very seamless.
And so you list your requirements at build time and at runtime in that YAML file.
And then Condo Build goes and installs that stuff.
And it is also doing a lot of kind of housekeeping as far as downloading the source and making sure that it's clean and then putting it in the right place and putting your prompt in the right place and activating VC Verazol, for example.
And just taking care of all of those details for you so that you don't have to learn to do it yourself or don't have to put up with doing it yourself.
That's nice.
So if I can get my thing to build on one platform, how hard is it to get it to build on all the platforms?
It depends heavily on which package.
I mean, some packages support all platforms pretty well, pretty natively.
But for example, some packages that really depend very heavily on Unix tools take a little bit more handholding on Windows.
There's a lot of other build tools that make life easier.
So for example, CMake is something that you always get really happy when you see that somebody's using that because it makes it much easier to do cross-platform builds.
Whereas some other projects will say, oh, I've got a make file for Unix stuff, so Linux and Mac.
And then on Windows, I've got this Visual Studio 2010 solution file.
So if you're on Visual Studio 2008, you probably can't use it.
If you're on 2015, you have to update it.
And maybe it works.
Maybe it doesn't.
So that's the kind of thing where some projects are a lot easier than others.
I would add, though, that for Python in particular, the recipe is usually trivial.
It's usually mostly just there's usually about three files.
There's a meta.yaml that is kind of like setup.py, except we use setup.py.
And then your build script is mostly just Python setup.py install.
And most of the time, you don't even include that.
If you look at most of the Python-based recipes on Conda Forge, there's just a single command to run that setup.py command in the meta.yaml file.
I see.
And that gets basically installed into that local Conda environment.
Then you just grab what you got and ship it?
Exactly.
So what Conda Build is doing is taking a snapshot of the files after it creates the environment.
And then another snapshot after it's done doing whatever you told it to do to install it.
And then those are the files that make up your package.
Okay.
This is excellent.
Yeah.
So it sounds like the Conda environments play a super important role.
And the fact that Conda can install the tool chain as well is really important in making this all work.
Yes.
It's not critical.
So the tool chain being a Conda package is actually something that we're working on.
You'll soon be able to install the compiler and the runtime libraries and all that stuff as dependencies.
You can currently, just not very many people do it because it's not supported all that well.
That's what we're moving towards our main way of doing things.
And what that'll mean is it's just going to be incredibly easy to, you're just going to be able to volunteer your machine as a build worker.
And as long as you have Conda build installed on it, it doesn't matter what else you have.
It'll take care of it.
Interesting.
So you mean like I could go and just say, hey, I'm willing to donate some of my cycles and disk and bandwidth to be a build machine?
Kind of like steady at home or protein folding, those things?
Yes.
That is the dream.
And there's quite a few technical hurdles to get there, but it'll be really neat if we figure it out.
That sounds awesome.
Yeah, yeah.
Very cool.
Okay.
So what are some of the challenges around, you know, linking all of these other GitHub or not necessarily GitHub, Git repos into like one sort of super master feedstock repo?
You know, because you've got all the recipes, but they all either in the Conda or Conda Forge, like kind of link back to all these other places.
Phil, do you want to answer that or should I?
You're welcome to answer it.
Okay, good.
I think the hard part is how do you do the maintenance work?
Because it works fantastically well to pull those submodules into one folder just as a view or as a consolidated place to work from.
But then if you change any of the source code, Git submodules are just unwieldy at best for pushing those changes back to the parent repositories.
So what Phil has created is fantastically useful for doing the editing on each repository.
But if there were like, say, a lot of edits you wanted to apply across a lot of different repositories, that's the kind of change that would be kind of tedious and hard to do.
Yeah, absolutely.
So what's that tooling look like?
We don't have any idea yet.
We're still working on it.
Just waiting for Phil to work his magic.
Yeah, yeah.
Please, Phil, figure that out.
So on the Condor Forge front, we actually have a Heracuse service that's running periodically to re-render all of our feedstocks whenever we make kind of fundamental template changes to how a feedstock should look.
And that service actually goes away, re-renders using the tools that we've built.
And then if there are any changes, pushes a new pull request to be merged by the recipe maintainers on GitHub.
So actually, it is tedious to have to make these changes to, like, we're up to 1,500 Git repos now.
It is tedious if you need to make those changes, but there are some tools that we've developed to simplify that if it's kind of a universal change that's needed.
Yeah.
To clarify what a re-rendering is, that is just, like, a change to the CI setup work.
And the re-rendering is to adapt the CI scripts to whatever the latest standard is.
I see.
Okay.
Yeah.
And what CI tools do you use?
That's the AppVeer and the CircleCI and TravisCI.
Okay.
Yeah, yeah.
Very nice.
And when do you choose which, or do you use them all and sort of somehow use them in concert?
Sure.
That's something that Phil figured out, and he uses AppVeer for Windows and CircleCI for Linux and TravisCI for Mac.
Phil, you want to explain why you made those choices?
I mean, the choices were pretty straightforward, really.
So, obviously, AppVeer is pretty much the only game in town for Windows continuous integration, or certainly was at the time.
TravisCI is ubiquitous, and everyone knows it.
And at the time, when we first developed CondorForge, there was either you could have very limited Mac builds or amazing Linux builds.
But you can have both.
So, we ended up having to go down the route of picking Travis for Mac.
And then, yeah.
You know, we've got to go down the route of the app, but we've got to go down the route of the app.
And then, yeah.
So, yeah.
Yeah.
That's really great of them.
Yeah.
Nice job.
Do you think you guys, you think, on a forge or the recipes, Feedstock is what it's called, is the thing on GitHub with the most submodules?
Oh, good question.
Thanks.
Yeah.
We're up to 1,500 recipes.
So, about 1,500.
It's pretty high.
It's got to be in the top five if it's not number one.
I bet it's number one.
That's really interesting.
Really interesting.
So, can you talk about the growth and some of the challenges, Phil, of CondorForge?
Sure.
So, I mean, we publicly announced CondorForge less than 12 months ago.
And the uptake curve on it was crazy.
In the first few months, we'd grown to 100 contributors and kind of 300 recipes or something like that.
It really is quite amazing that the infrastructure scaled so well.
I mean, we designed the architecture to have the ability to make lots of Git repos.
But we had really no idea whether GitHub were going to limit the number of Git repos we could have under one organization.
You know, the continuous integration services, we had no idea whether they'd be able to cope with so many kind of registered Git repositories.
There were some real challenges that actually just fell out quite nicely.
Yeah.
It sounds like the tooling worked really well, actually.
Yeah.
As it became more and more mature, the bottleneck, it turns out, has not been the hardware.
Actually, the biggest bottleneck probably is me.
And just kind of developing the governance and the kind of delegated authorities to kind of make decisions without my intervention just takes time.
And it's actually kind of the fluffy thing that's much harder than the software for me.
There's no script for that, is there?
No.
There's no continuous integration service for that.
Hey, everyone.
Let me take just a quick moment and tell you about a new sponsor of the show, MongoDB University.
MongoDB is one of the fastest growing job skills on the market.
Long ago when I was getting into MongoDB, I took one of their free courses on Mongo University.
It was a great way to get up and running with my first app.
MongoDB University offers free seven-week courses on MongoDB designed to teach you everything you need to know about how to build a MongoDB-based app.
This course will cover basic installation, JSON, schema design, querying, inserting data, indexing, and working with the Python driver, of course.
After completing this course, you should have a good understanding how applications are built on top of MongoDB using Python.
Plus, you'll have a great foundation for preparing for the MongoDB developer certification exam.
I hope you can join me as a MongoDB University alumnus.
Sign up for the free seven-week course at talkpython.fm/Mongo.
Kale, let's talk a little bit about some of the projects under github.com/Conda.
Sure.
So there's a few that are interesting to me.
There's Conda and then there's Constructor.
What's the story of those?
Yep.
So there's Conda and CondaBuild.
Those are the two big ones that we've been talking about.
There's Constructor.
And Constructor is actually a lot of what we use to build the single installer, the Anaconda Distribution installer, at least the .sh ones.
And so it creates a self-extracting binary into a single .sh or executable file will unroll itself and install all those packages for you.
That's what Constructor is.
Some of the other ones, CondaM is on there, but it's deprecated.
It's been pulled into the Conda repo now so that they can be tested together and shipped together and versioned together and stuff like that.
There's Capsule repo.
And Capsule is a bit of an experiment for Continuum right now.
It's really focused on more managing data science projects, starting services that are dependencies for data science projects like Aretis database or something like that.
So it takes all the ideas of Conda's package management, environment management, adds services, adds running processes to it, and then adds data to it as well.
So data shape, schema, stuff like that.
Wow.
That sounds pretty interesting.
So if I want to do something where I'm going to need a Jupyter Notebook server running, I'm going to need Redis, like you said, and a few other things, that could sort of do that all in one shot?
And then in a portable way so that you can move projects around from a local dev environment to something that is sort of running in production and against your production database.
Even Conda, one of the great things is it's completely OS agnostic, right?
So being able to port your projects across OSs and share your projects that way too.
Cool.
How does that help for reproducibility?
Like if I'm a scientist and I've written a paper, can I make a capsule thing and go, and this is the thing that will let you go and do it?
I can see that happening.
Yeah.
Very, very, very cool.
The starting point, if you want to examine my data yourself, here's all the tools you need to do it.
Run a command and you're in.
Okay.
Excellent.
And Phil, how about the Conda Forge Conda Smithy thing on GitHub that you guys have?
What's that?
Right.
So as I say, we've got like 1,500 recipes now that are sitting each in their own Git repository.
And the Git repository that holds the recipe is called the Feedstock.
And as you can imagine, there is duplication of things like the readme and the license and the continuous integration scripts.
And we didn't want to have that kind of duplication where we had to manage that manually.
So Conda Smithy really is the tool that is the cookie cutter, the templating engine that takes a recipe and turns it into this Git repository.
I see.
So if I owned a package and I wanted to get started, maybe I'd check out Conda Smithy to build what I'm going to start with?
Yeah.
You can render your recipe into a feedstock and see how that would look.
And actually, that's precisely what we do.
The turn recipes proposed to Conda Forge into feedstocks.
And the tooling in Conda Smithy also includes the ability to make the new GitHub repository.
It registers all the webhooks.
So you can kind of automatically register Travis, Circle, and AppFire continuous integration.
It just kind of packages everything neatly into one place so that we don't have to repeat ourselves 1,500 times.
Yeah, absolutely.
And make it easier for people to contribute.
All right, guys.
Looks like we're running out of time.
I think we might have to leave it there for Conda.
But let me ask you each two questions.
I always ask at the end of the show.
Just there's three of you.
You go kind of quick.
First of all, there's over 90, I think 95,000 packages on PyPI and many of them on Conda Forge and within Anaconda.
Can you each give me maybe one of your favorite packages that's not necessarily popular but you think is really cool that people should learn about?
Phil, go first.
I'm going to pick a package which is extremely popular but it's so exciting.
I'm thrilled that it exists.
My favorite package is Dask and Dask Distributed.
I think it's just an amazing solution to a really big problem within the community.
Yeah, so this is like for parallelizing data pipeline type processing?
Right, exactly.
Yeah, and parallel array computation.
Just really exciting.
All right, Dask.
Dask, very cool.
Cale?
Yeah, the two packages that popped into my mind are Mahmoud Hashimi's Boltons.
I love that.
I use it all the time.
And then Matt Rockland's PyTools, SciTools.
Both fairly low level but both awesome libraries for writing general Python and using both all the time.
Oh, excellent.
Yeah, I've checked out Boltons.
Not the other one.
I'll have to have a look at that.
They're both, you know, both sound great.
And Michael?
pytest.
Yes, pytest.
To make sure all these automated builds actually have some sort of meaning, right?
Yeah.
And also just all the plugins that go with pytest.
Let it do incredible things in very expressive ways.
I'm very, very thankful for pytest.
Excellent.
All right, Michael, when you write some Python code, what editor do you open up?
SpaceMax.
All right on.
Cale?
For Python code in particular, it's PyCharm.
PyCharm.
Okay, cool.
And Phil?
I'm mostly a Vim user, even on Windows.
Okay.
Yeah, yeah.
Very nice.
And I guess the legitimate real Vim and the Unix tools are supposed to be there soon.
Are they already there?
I'm not sure.
But the Unix...
In Conda?
No, no.
In Windows 10, it's supposed to have the Ubuntu subsystem in it natively pretty soon.
Maybe that'll even help with some builds.
Who knows?
But, yeah, yeah.
Very cool.
Do we have Vim for Conda?
Has it been written?
Does anybody know?
I'm just curious.
I don't know.
I wrote Nano a long time ago.
Is it on Conda Forge?
Phil, do you have Vim compiled yet on Conda Forge?
I know of.
But then, you know, I'm completely out of the loop.
Sounds like somebody should take that one on.
Awesome.
All right.
Any final call to actions?
Like, how can people contribute to this overall project that you guys are all working on?
Vim for Conda Forge, apparently.
That's step one.
Oh, I have one.
I released Conda 4.3.0 today.
It's a huge feature release.
It's over almost 900 commits past the 4.2 feature release or feature branch.
It's released on.
We have a Conda Canary program.
So just like Chrome has a Canary program, I kind of ripped off the title.
Plus, there's some alliteration.
So Conda Canary.
And you just add a Conda config, add channels, Conda Canary.
You add the Conda Canary channel.
Check it out.
Use it.
Let us know what you think of it.
The changelog is extensive.
And we'll be releasing it, general availability, probably on the last day of 2016.
Oh, perfect.
A nice New Year's gift.
That's awesome.
So yeah, people check that out.
Anything else?
I'd say if anybody is missing a package on Conda that is in PyPy and it would make your life easier,
then please submit a recipe to Staged Recipes.
And the main thing I would emphasize about Conda Forge is the really incredible thing about it is the community.
There is such an amazing pool of expertise there on how to build software.
And I've learned a lot.
And anybody stands to learn a lot just by getting involved there.
Okay, excellent.
Yeah, absolutely.
Easy to contribute and please do so.
Any of you guys going to be at Anaconda Con in Austin in February?
Oh, yes.
Kale?
We'll be around.
Yep, absolutely.
Nice.
Phil, are you traveling like halfway around the world?
Unfortunately, I won't be there for Anaconda Con this year.
All right.
So if people make it, go say hi to Michael and Kale and we can tweet.
Tweet at Phil.
All right, guys.
Thanks so much for being on the show.
It's been great to talk about Conda.
I think it's a really great project overall that you guys are working on.
So thanks for that.
Thank you, Michael.
Thank you.
This has been another episode of Talk Python to Me.
Today's guests have been Phil Ellison, Kale Franz, and Michael Sarahan.
And this episode has been sponsored by Continuum Analytics and MongoDB University.
Thank you both for supporting the show.
Whether you want to hear the keynote by Ryan Curran from Forrester Research,
meet the guys behind Anaconda, or just mingle with high-end data scientists,
you need to find your way to Austin, Texas for Anaconda Con this February.
Start at talkpython.fm/acon.
Get the skills you need to build your Python apps on top of the most successful
and in-demand document database at MongoDB University.
Take a free class by visiting talkpython.fm/mongo.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart,
by building 10 apps at talkpython.fm/course
to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced,
try my WritePythonic code course at talkpython.fm/pythonic.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes,
Google Play feed at /play,
and direct RSS feed at /rss on talkpython.fm.
Our theme music is Developers, Developers, Developers by Corey Smith,
who goes by Smix.
Corey just recently started selling his tracks on iTunes,
so I recommend you check it out at talkpython.fm/music.
You can browse his tracks he has for sale on iTunes
and listen to the full-length version of the theme song.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Smix, let's get out of here.
I'll see you next time.
Bye.
you