Visit our site to listen to past episodes, support the show, and sign up for our mailing list.
Summary
Anthony Scopatz is the creator of the Python shell Xonsh in addition to his work as a professor of nuclear physics. In this episode we talked to him about why he created Xonsh, how it works, and what his goals are for the project. It is definitely worth trying out Xonsh as it greatly simplifies the day-to-day use of your terminal environment by adding easily accessible python interoperability.
Brief Introduction
- Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
- Subscribe on iTunes, Stitcher, TuneIn or RSS
- Follow us on Twitter or Google+
- Give us feedback! Leave a review on iTunes, Tweet to us, send us an email or leave us a message on Google+
- I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show you can visit our site at pythonpodcast.com
- I would also like to thank Hired, a job marketplace for developers, for sponsoring this episode of Podcast.__init__. Use the link hired.com/podcastinit to double your signing bonus.
- Linode is also sponsoring us this week. Check them out at linode.com/podcastinit and get a $10 credit to try out their fast and reliable Linux virtual servers for your next project
- We are recording today on October 12th, 2015 and your hosts as usual are Tobias Macey and Chris Patti
- Today we are interviewing Anthony Scopatz about Xonsh
Interview with Anthony Scopatz
- Introductions
- How did you get introduced to Python?
- Can you explain what Xonsh is and your motivation for creating it?
- For people transitioning to Xonsh from a shell like Bash or Zsh, what are some of the biggest differences that they will see?
- What are some really powerful one-liners that showcase Xonsh’s capabilities?
- What is it about Python that lends itself to this kind of a project and what are your thoughts on building something like Xonsh in another language such as Ruby or Node.js?
- If you had to single out one killer feature that Xonsh brings to the table, what would that be?
- Is it possible to specify which shell, such as bash or zsh, gets used in subprocess mode?
- I started using the Xonsh shell as my daily terminal recently and have been enjoying it so far. One of the things that I have been wondering is how to hook into the completion system to provide eldoc style completion from parsing the output of help flags. Do you have any advice on where to start? Perhaps using the docopt library to handle parsing of help output and generate completions from that?
- What are your thoughts on adding a section to the project documentation for people to list various extension modules that people can take advantage of? Or perhaps creating something along the lines of Oh my Xonsh?
- How do bash function definitions interoperate with the Xonsh environment and functions defined in Python?
- It seems as though there could be some potential path or compatibility issues when moving between virtual environments and having access to extension modules loaded into Xonsh. Can you shed some light on that?
- Do you have any suggestions for people who may not have the privileges to set their own login shell but who want to try Xonsh?
- What are some of the most interesting uses of Xonsh that you have seen?
- What does the future hold for the Xonsh project and how can our audience help?
Picks
- Tobias
- Chris
- Anthony
Keep In Touch
Links
The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA
Hello, and welcome to podcast.init, the podcast about Python and the people who make it great. You can subscribe to our show on iTunes, Stitcher, TuneIn Radio, or add our RSS feed to your podcatcher of choice. You can also follow us on Twitter or Google plus with links in the show notes. And please give us feedback. Leave us a review on iTunes, send us a tweet, send us an email, or leave a message on Google plus. You can also leave comments on our show notes. Feedback helps people find the podcast so that other people can enjoy it as much as you have. I'd also like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show, you can visit our site at pythonpodcast.com.
I would also like to thank Hired, a job marketplace for developers, for sponsoring this episode of podcast.init. Use the link hired.com/podcastinit to double your signing bonus. Linode is also sponsoring us this week. Check them out at linode.com/podcastinit and get a $10 credit to try out their fast and reliable Linux virtual servers for your next project. We are recording today on October 12, 2015, and your host, as usual, are Tobias Macy and Chris Patti. Today, we're interviewing Anthony Skopatz on Zansch. Anthony, could you please introduce yourself?
[00:01:25] Unknown:
Hi, everybody. Thanks, Tobias, and thanks, Chris. I am a new faculty member at the University of South Carolina, which is currently not as much underwater as it was last week, so thank you for small miracles there. And I'm a nuclear engineer, nuclear engineering professor, so I'm in the mechanical engineering department here. And I've, you know, come from a physics background and have been involved in the Python scientific computing community for a long time, and that's about where I am.
[00:01:56] Unknown:
That's great. How did you get introduced to Python?
[00:02:00] Unknown:
Well, you know, a Python killed my mother.
[00:02:07] Unknown:
Prepare to die. Yeah. So
[00:02:10] Unknown:
yeah. That went to a dark place. So I actually got introduced to Python through portage. So on gen 2, the package manager was, my first introduction to to Python, and that was 2, 001 or so. So I sort of just arrived at 2, 002, I guess. So I just arrived to college as an undergrad and was fooling around with computers a lot. Yeah. I mean, that that's sort of where I learned the shell and learned Python and and everything. I learned a few great good languages in that time period, and everything else I've seen has just not really been up to snuff.
[00:02:49] Unknown:
That's a very interesting standpoint on it because there definitely are plenty of languages out there, and I have to agree that Python is the 1 that I find most comfortable to work with. So it's interesting that you have found so many of them to be lacking.
[00:03:02] Unknown:
Yeah. Exactly. It's not categorically true. There are other, I think, there are other languages that I find interesting. You know, something from the functional world, maybe like Haskell is cool. Lua is a neat little language that I like for a lot of reasons, but, you know, if if you're talking about languages like Bash and c plus plus and JavaScript and Java and sort sort of the other big heavy hitters that are out there today. None of them really give me that kind of expressiveness that I that I demand.
[00:03:33] Unknown:
I think part of the appeal for Python is because of the fact that it does such an excellent job of fulfilling multiple paradigms, whereas a number of other available languages are a little bit more limited in the ways that they can be used or the ways that you can use them to think about the problem you're trying to solve. Right.
[00:03:50] Unknown:
Or the ways that their communities have enabled them to be used. If you know what I mean, like Ruby has a tremendous amount of tooling and library support if you're writing web apps or if you're writing infrastructure as code stuff, but maybe not so much for writing GUIs or, you know, or doing scientific work, just as an example.
[00:04:11] Unknown:
Yeah. I mean, there's absolutely no doubt that the ecosystem is what keeps me in Python at this point. 10 years ago, or 15 years ago when I started, you know, the ecosystem wasn't necessarily there. And so I've gotten to see a lot of that get built up over time, and that's been just a real, real blast. And it's been really great to see that happen.
[00:04:34] Unknown:
So can you explain what Xonsh is and your motivation for creating it?
[00:04:38] Unknown:
Sure. So Xonsh actually comes out of, this exact issue. Right? So I was I was writing a lot of bash at my old job or doing a lot of bash and sort of c make stuff for build systems, and I just realized that there had to be a better way than what bash was doing. So that kind of set the stage for really thinking sort of very critically about what shells get used for and what they're actually good at and and what they're not good at. And then back in February or so, I was writing the I wrote a book with my lovely coauthor, Katie Huff. It's called Effective Computation in Physics. You can go, and you can look it up. It's it's on it's by O'Reilly. They put it out, so thank you very much to O'Reilly for letting us publish that.
But Katie had written the the bash chapter. So chapter 1 is all about bash, and I was reviewing this chapter on bash, going over it. And I I got to the end of the chapter, and I realized we hadn't even covered the sorts of things that you would cover in a normal programming language. Like, there was nothing about flow control, there was nothing about data types, or really data types, in in bash. There's a couple, but nothing nothing worth noting. And but instead, we went over a lot of, like, this arcane syntax that people sort of only have to use for batch. And so at that point, it it really clicked that, hey, I can do this better. Right? Like, what if what if we just had Python and and Bash together, like, the good parts of both and the the the bad parts of Bash removed?
[00:06:21] Unknown:
That's really interesting. You hit on something there in that. I've actually been doing, some some more in-depth work with bash recently myself. And for a language that is perceived as to be simple, it actually has quite a bit of surface area that you need to be mindful of if you're gonna use anything more than really basic sort of procedural batch language capabilities
[00:06:45] Unknown:
in it. Right? Right. Who knows how to, like, do a case statement in batch off the top of their heads? Or, like, the 3 different ways to define a function or, you know, even for loops are super annoying, and if statements, they're just it's all it's really bad from a language design standpoint. It's really bad. You have to give them credit. It's like a it's a super old language, and it's got all this craft, and it's been built up over, you know, decades. So it's obviously successful.
[00:07:14] Unknown:
And the majority of use, at least in my experience, for using Bash is just as a way of gluing together multiple other ancillary programs like awk and sed and grep. And like you said, trying to actually remember any of the specific features of bash for doing anything beyond just piping those things together, like for loops or if statements. I just have to look it up every single time because it's just so obscure in relation to the ways that those things are defined in most of the other higher level languages like Python or Ruby or Java, just anything.
[00:07:49] Unknown:
I mean, it's literally like you're casting spells. Right? You have to remember these weird, like, somatic movements and put them into the keyboard, and it's it's just it's yeah. It's very arcane.
[00:08:01] Unknown:
So for people transitioning to Zhan from a shell, like Bash or Zeesh, what are some of the biggest differences that they will see?
[00:08:08] Unknown:
Hopefully, that transition is easy. So that's 1 of the things that we set out to do or I set out to do with Conch is to make it so that it interfaces with, Bash and Z Shell and and can pull the environment and aliases from from those those places. So that's that's 1 thing that our that Conch does that's a little different is that it has sort of knowledge of other shells in a way that, in a way that most shells don't. And then I think just the the big difference is that you can use Python syntax everywhere. So, I mean, it's a Python superset language. So anything that's in Python goes, and this is, you know, this is true. We just released this today, actually, out into the wild.
Python 3.5 is now fully supported, so just go at it. Have fun. So that I mean, that that does a couple of things for you. Right? So the the sort of really naive thing that you might wanna do is just simple arithmetic. Like, this is super annoying in in other other shells. But you once you have that, you can also start doing things like, you know, importing libraries and calling different functions from those libraries and, you know, using those to string up these higher order complex operations. You can define functions in a way that makes sense and, you know, just just all of the stuff that's in Python, you can you can now do in your shell. The other thing that I think that's significantly different is a notion we have a really structured notion of history, and we have an optional capability where you can actually store all of your standard out and standard error, along with your, you know, just a normal standard in and and return values and things like that. So if you're in this sort of scientific competing space where you wanna have perfect complete memory of what you did, you know, last month, that's something that you can do in conch natively without having to think twice about it. And from there, there's other cool history things like you that you can do. You can, you know, very easily use those as their scripts by replaying history or you can diff 2 histories to see you know, you can take a history that was built on 1 machine and replay it on another machine, diff them, and and see kind of what was different and what's causing problems and and things like that. So, there's a lot of sort of features there that aren't in these other languages.
[00:10:41] Unknown:
And so 1 thing that that brings up is for cases where the standard out stream is particularly large, is there a way to limit the
[00:10:56] Unknown:
there's a there's a fully that that's all customizable. There's a garbage collector that gets run every time you start up conch. So if you wanna limit your total history stored to some value, you can. And I think the default is something, like, around 8, 000 commands, 8, 128 commands. But you can fill you can instead store that by, you know, gigabyte, or you can limit that by, you know, number of files or a a lot of other options or how long ago things were the history was created, you know, things like that.
[00:11:33] Unknown:
Very cool. So when I ask this, I'm not necessarily asking you to recite them, but I'm just asking you to give us our our listeners a sense. What are some powerful, really powerful 1 liners that showcase Sanchez's capabilities?
[00:11:49] Unknown:
Yeah. So since you can do a lot of, like, cool Python things well, so 1 of the 1 of the cooler things that you can do is you can define aliases with Lambda functions. I mean, you can define aliases in cons with any function, but you can also define them with Lambda. So you can define an alias, with a Lambda, add it to the alias' dictionary, and then immediately execute it if that's something that you wanted to do. I mean, other other cool things is that we have a distinction between sort of a captured subprocess and an uncaptured subprocess. So con Conch kind of executes subprocesses in these 2 modes. So the uncaptured 1 is, like, if you're just sitting there typing away, you know, echo hello, and it'll spit something back out at you.
But there's also just a a Python expression that you can use, dollar sign parenthesis, just like in bash, to grab that as a string. And then once you have this, you know, shell executed, subprocess executed thing as a string, you can do whatever you want with it. So say you have, you know, like a a JSON file that you're curling, You can curl that directly, capture it, and then use, you know, JSON dot load to load it right into a a Python dictionary as a single expression.
[00:13:16] Unknown:
Yeah. That's that's really kinda neat. So if you're interacting with APIs that you're not entirely sure of, I can see that as being a really neat way to support kind of an iterative style of, you know, sucking a blob of response from the server and then sort of, like, say, you know, transform it into into JSON and parse it that way and, like you said, sort of see whether a dictionary makes sense or some more complex data structure all on the fly. That sounds really cool.
[00:13:44] Unknown:
Yeah. Yeah. I mean, it's supposed to make your life easier. Right? Like, I think a lot of tools. So there's a lot of other ones out there that I'm sure people have come up with that I'm not aware of, but sort of those are the ones that are kind of fun to me. Do you folks have any place where this kind of thing is collected? Like, is there a sort of Zaunch
[00:14:03] Unknown:
brag page? Like, here, now you've installed Zaunch. Here are some of the really cool things you can do kinda thing?
[00:14:09] Unknown:
Not yet. There there definitely should be. I I would really love it if there was something like that, you know. So very early on, we got requests for, like, a concert, like, oh my oh my con shell or whatever kind of capability where people could share those those 1 liners or those tools that they've built. I haven't built that out yet. I'm be really interested if someone wanted to do that. That'd be awesome. So
[00:14:36] Unknown:
100% support that, but we could also just have a landing page, like you said. Yeah. I definitely think that having sort of a list of available modifications that people have made so that other people can pick and choose what would be most useful for them would be really valuable. Because while it is Python and you can customize it in whatever way you can possibly dream of using Python, it is useful to have something to spur those ideas when you're first getting started out with it to say, oh, well, I didn't even think about being able to do this with that.
[00:15:06] Unknown:
Right. Yeah. No. It's cool. It's a good idea.
[00:15:10] Unknown:
So what is it about Python that lends itself to this kind of a project? And what are your thoughts on building something like Xonch in another language such as Ruby or Node.
[00:15:18] Unknown:
Js? That's a good question. So I think Python lends itself to this kind of thing because in part, that's sort of what its original goal was in in some sense. So Guido has some quote about I'm not gonna remember it off the top of my head. I'm sorry. But he has some quote about having written Python to make systems programming and scripting easier for people. Right? And it's kinda like if I recall correctly, he had this sort of librarian use case in mind when he set set out to do a lot of this stuff. And in a lot of ways, I think Python, like, you know, core Python kind of failed at that because it became this general purpose programming language. It wasn't confined to to its original shell, shall we say.
And so because the things that you need to do to make something in a shell are kind of are somewhat incompatible with what you want in a general programming language, And so it would it takes this other project to to come in and and fill that role. And, you know, I I think conscious the answer I'm actually surprised no 1 had done it before in some sense. It might have seemed too hard, but it it actually didn't really take me that long to get a first cut, that was fully working. So, you know, and and I'm 100% in support of people doing this for other languages. I think it's actually a good idea, because I I don't think there's anything necessarily special about the shell use case that would kinda force a new language on people.
Node. Js might be interesting because it has sort of it's got this asynchronous implementation. It's my understanding. I don't don't do a lot of node stuff, but I mean, it would it would be cool to see how people resolve those issues there. And there is someone who is doing, who has an OCaml sort of idea that came out in the past couple of months, so I'll I'll try to look that up and send you that for the show notes. But, yeah, I think it's a good idea. You know, you your shell should not get in the way of you programming, And so but if your native language is Python or Ruby or c plus plus or whatever, you should be able to have a fully fledged shell in that way.
[00:17:46] Unknown:
I have to confess the idea of a node dot JS shell kinda makes me shiver. Like the, like, event, you know, event, like, event driven and callback driven, shell programming just seems like it might be make my brain hurt a little bit, but, you know, who knows? I don't really know node, so perhaps I'm casting it in an unfair light. Yeah. Well, I mean, I think that's part of the
[00:18:09] Unknown:
that's that's why I think there'd be a lot of, issues to resolve there, how how you express those things, but good luck to whoever does it. I'm out. I'm done.
[00:18:26] Unknown:
So if you had to single out 1 killer feature that Xonsh brings to the table, what would that be?
[00:18:33] Unknown:
Yeah. So if I had to say, I I would I think it is just that, it it is Python, and the shell stuff is exactly what you would expect from a shell language. So you don't have to say not to pick on IPython, but you don't have to open up IPython to do the kinds of things that you need to do, or you don't need to go into a a Python shell to do that, and then import subprocess and do a bunch of subprocess manipulation, which can get tedious if you're doing it for, you know, many, many, many calls. So the the real killer feature is that it just it takes care of all of that stuff for you, and it it lets you get straight to the task at hand, whatever that task is.
[00:19:22] Unknown:
And so is it possible to specify which shell, such as bash or z each gets used in subprocess mode?
[00:19:28] Unknown:
So so no no subprocess is a shell unless you tell it to me, or is a foreign shell like bash or c shell. We're we're literally using subprocess under the covers. So subprocess doesn't it does a system call. It doesn't make a call to another shell and then run that in its own shell. It just goes out to the operating system and says, hey. Run this. So bash and z shell aren't really present for any anytime you're in subprocess mode. It's just a straight straight up system call or operating system call.
[00:20:06] Unknown:
And as a corollary to that, what does the migration path look like for somebody moving from Bash or Xeesh or Phish to Xonsh and who want to try and keep the different customizations that they've already made to their existing shell environment while still being able to leverage the power of Xonsh?
[00:20:24] Unknown:
Yeah. So, we've tried to make that easy. I'm I'm sure there's still hiccups here and there. But so there's a couple different things that people worry about. So the the first is sort of the setup stuff that you talked about. Like, I've got thousands of aliases and, you know, my my bash RC is huge, and it's got all these environment settings. I don't wanna rewrite that just to try your code out. And so, as of 0.2.1, Conch allows you to specify, an arbitrary number of what we call foreign shells, like bash or seashell or fish, And that it will, on startup, take the environment and aliases from.
And so it just runs a subprocess of that shell, steals out the environment and the aliases, and then returns and applies that to the environment for that Concha is gonna use. So the default is just to use bash, but or you can change that default if you need to. The other thing that people really worry about in in my in migrating is if you need to source a foreign shell script. So this happens in Bash a lot where, you know, even PIP or, you know, Virtualenv does this when you wanna go and Conda does this. When you wanna activate an environment, you have to source this other file. And so what we have is a we have an alias that you can use that will source the environment from a shell that's in another language. So, and aside from that, the migration is actually pretty easy. Right? Because you can always run bash from within consch or, you know, the language is much simpler and, arguably, you already know it. So if you need to port over a bunch of if statements and functions and stuff, it's it actually ends up looking a lot nicer and is a lot shorter in the long run. So kind of the migration story.
[00:22:29] Unknown:
So I started using the Xon shell as my daily terminal recently and I've been enjoying it so far. And 1 of the things that I've been wondering is how to hook into the completion system to provide LDOC style completion from parsing the output of help flags. And I'm wondering if you have any advice on where to start. And 1 thing that I thought as a possibility is using the docopt library to handle parsing of that help output to generate completions from that.
[00:22:51] Unknown:
Yeah. So that's a that's a really great, great question. So this is on our to do list, in some in some sense, although contributions welcome. So there there's a couple different ways to hook in. So we have a completer class, so that could always be extended. Something that we do actually also is that we are able to incorporate any bash completion files, and that happens automatically. So if you have it's bash completion stuff installed, no one's gonna rewrite that. So we just when you hit tab, the tab complete, and and there's a it's a git command. It'll actually go and make a a bash complete call to pull the possible completions out.
And something that we've wanted to do for a while is to be able to have an interface that's written in pure Python. You register some functions, and it goes ahead and executes, and finds the possible completions. But, and if anyone wants to tackle that, they're they're more than welcome to.
[00:23:56] Unknown:
So 1 complication I actually ran into recently of trying to use some batch completion files on my system was, at least a couple of versions ago, I was trying to add some batch completions. And there was a particular function definition for have that was being called in some of those files that didn't exist in my environment. And so I was trying to figure out how to define that function before the bash completions were getting resolved and wasn't quite able to figure that out. Although part of that might have been due to a bug that got fixed in the most recent releases that you just made today and yesterday, actually.
[00:24:35] Unknown:
Yeah. Probably not, sadly. So the the bash completion stuff kinda runs in its own, own little environment. But, yeah, I mean, you'd have to probably go and make sure that the batch completion function this is getting into the weeds, but the batch completion files that you're sourcing I mean, this might be a way to do it is to add another element to the batch completions environment variable that has whatever functionality you need to make sure that it's there.
[00:25:08] Unknown:
Part of my problem might have been that I wasn't use I wasn't sourcing the bash completion file. It was s e sc completiondashcompletion, I think was what it was. So I probably wasn't sourcing that early enough, and that might have been what was leading to my issues.
[00:25:22] Unknown:
We're a new project. I have great faith that all this stuff will get resolved in time, but, you know, we'd love to help in the in the short term to to really build out the the pieces and the capabilities of things that people want sooner rather than later.
[00:25:38] Unknown:
And we've touched on this a little bit, but how do batch function definitions interoperate with the Xonsh environment and functions that are defined in Python? We don't currently have the capability
[00:25:49] Unknown:
of having consch run generic bash functions like Python functions, that could be added. It wouldn't be terrible, to do that. It wouldn't be that hard. It wouldn't be that many lines of code, I'll say. And so so that's 1 way. I mean, if you if you write a batch function and then use that in a batch script that then use source, like, that's all fine. But just having them appear magically in the in the Python context, that doesn't happen
[00:26:21] Unknown:
yet, but probably should. Yeah. That leads to the possibility of an interesting project is being able to write a bash to Xonch transpiler. Yes. Yeah. Seems like a hairy problem and 1 that I'm not likely to engage in. But if anybody else out there is interested, then I would definitely be interested in hearing about the outcome.
[00:26:43] Unknown:
We need to find some 16 year old Savant who, has and give them a lot of Mountain Dew or something.
[00:26:53] Unknown:
So it seems as though there could be some potential path or compatibility issues when moving between virtual environments and having access to extension modules loaded into Xonsh. And I'm wondering if you can shed some light on how that plays out.
[00:27:05] Unknown:
When you go into a virtual environment I'm not a super expert on virtual environments, actually. So but when you go into a virtual environment, you get your own you're basically making modifications to environment variables is my understanding of how it works. Yep. And so that gets done. And those modifications happen when you source the activate file. Mhmm. And so since we have the capability of sourcing that file, virtual environments should work. And I guess your question is what happens like, which version do you get when you've when you import something then after that? Yeah. I think you would have to if you want the virtual m source, you would have to have or you if you want the virtual environments extension to have been imported, you would have to start up Conch in that virtual end. I think that's the the right answer.
[00:28:06] Unknown:
Yeah. I was mainly curious about how that would work in terms of if you are using Xaunch and you have loaded some various different libraries into your shell environment and then you go ahead and source a virtual end, whether those libraries that you've already loaded would still be accessible or if there would be some contention issues if you have different versions of those libraries in your virtual end or also even if you're using a different Python interpreter within that
[00:28:40] Unknown:
Yeah Yeah. So, I mean, the the the answer there is that every time you start up Conch, you get your own I mean, you're starting it up through a new Python interpreter, and so you get whichever Python interpreter your environment was told to use. And so if that's, you know, 3.4, but in your, virtual env, it's 3.5 and you start up a conch shell in in a in a new virtualenv, then you're gonna get the 3.5 version, and then whatever imports you do. So it's all kind it's all self contained. Okay. It's like if you had started up Bash inside of a 1 version of Bash inside of another version of Bash. Right? There are different interpreters. Certainly.
[00:29:25] Unknown:
Yeah. Each has its own UNIX process context. I think that's an important thing to to bear in mind. Is even though it's all Python, the Unix process model keeps you from shooting yourself in the foot too horribly because it's not like you're gonna have different versions of Python sort of intermingling at the bytecode level because they're all running in their own process.
[00:29:47] Unknown:
Right. Exactly.
[00:29:48] Unknown:
And that actually brings up another topic that we haven't covered yet is that Xonsh is fully cross platform including Windows, if I'm not mistaken.
[00:29:57] Unknown:
Yeah. That that's correct. So, I mean, the the way this all works, actually, is that we it conch is completely it it's basically like it's 100% pure Python. There's nothing no extension modules in there, and we only have 1 dependency currently, which is ply. And I've thought about bringing that in so that we only rely on the standard standard library. But the the trick here is that you can use ply to, so you can build up a parser in Py that then produces a Python syntax tree, even for the the subprocess interface. All that just becomes at some a Python syntax tree. And so you can get that and then compile it down to Python bytecode and and roll from there. So it's actually very portable.
[00:30:54] Unknown:
And speaking of dependencies and libraries that are being pulled in, I know that a little while back, somebody added support for the prompt toolkit as a back end for the parser and the displaying, you know, in place of high read line library. And I know that that's still a little bit rough around the edges. So I'm curious any advice that you might have to people who are trying to use prompt toolkit as their main environment within Xanche?
[00:31:25] Unknown:
Yeah. So the prompt tools toolkit stuff has been been really great. So any anyone who's dealt with Readline knows how awful it can be. And then prompt toolkit to give people some background is is sort of a pure Python alternative to ReadLine. I I don't wanna say it's a clone because I don't think it it certainly doesn't implement the same interface, but I I don't think it even really interacts with it in the same way. And so this was written by a prompt tool kit was written by a gentleman, I believe, by the name of Jonathan Slenders. Slenders. Yep. Yeah. Yeah. We had the pleasure of interviewing in a previous episode. Oh, awesome. Yeah. He seems like a cool guy. So, I had sort of put up on my this would be cool idea, list that it would be cool to have, an interface that use PropToolkit.
And a a lady by the name of Anna worked on that, and then she got an, an internship at Facebook over the summer and didn't do much work on it after that, but might return to it. She's an undergrad CS person, I believe. So it was awesome that she put that in, and it was working and everything, and then sort of prompt toolkit keeps changing and and evolving. And every time an issue comes up, I basically ping Jonathan and say, help. I don't you know? Like, you're you're changing things. I don't know what to do. But it's it's cool. I mean, a lot of people ask for sort of a more fish like interface, and so, you know, if if you're of an Aquarian persuasion, then, that that is what you'd want to be using. And especially if you're on Windows and and Mac. Prompt prompt toolkit has sort of smoothed over a lot of the issues on on Windows and Mac, because read line can be kinda hit or miss on those platforms.
So
[00:33:27] Unknown:
And so 1 of the things that I've experienced in using both the pyreadline and the prompt toolkit backends is that some of the key handling, particularly for things like control z and control d, are a little bit different between the 2. Most specifically in prompt toolkit it appears that control z just doesn't work at all, at least right now. So I'm just curious how the key handling comes into play within Xonch and also taking into account the 2 different back ends that are available.
[00:33:59] Unknown:
Yeah. So, I mean, we, I I believe that that specific issue is, is a prompt toolkit 1, but, you know, basically, what ends up happening is that, Assange has to has to sort of set things up in the right way when it's setting up whatever back end, back end interface it wants to use. And so there's sort of 2 potential problems there. Are we setting it up correctly and in the same way across all back ends? That should be a yes, but might not be. And then are the back ends actually doing what you think they should be doing? And I would say I've had no end of problems with readline in that department.
And the prompt toolkit issues tend to get resolved, you know, relatively quickly because Jonathan will put in a pull request to Conch when when it needs to happen. But other people can can dive into the code. It's actually not that much code there in either of those classes.
[00:35:07] Unknown:
So And so while we're on the subject of diving into code, I'm curious what your advice to anybody is who is interested
[00:35:21] Unknown:
the the language and making language modifications, like, there there's certainly some room to grow there. And so looking at looking at the Lexor and parser files, lexor dot py and parser dot py, is probably where you'd go. You know, I I'm trying to be as liberal and generous as as humanly possible on for things like aliases. So if people wanna create a really big suite of aliases and then and then put those in sort of the Conch standard library of sorts and, you know, by all means, go to aliases.py and and and start writing things. If you want to deal with how the how the shells themselves work, there's kind there's a simple class hierarchy.
So there's a base shell, and then there's the red line shell and the prompt toolkit shell on the same level, and then there's just a shell class, that picks between them based on whatever user input was given. So, you know, there there's sort of those kinds of things, and then there's there's there's other capabilities, sort of the extras that make it make it worthwhile. Like, looking at the completer, we could we could have a better mechanism for doing completions from man pages. We've done a little bit of that, but, not not necessarily enough.
And if you wanna dive into the history, there's a history dot 5 file, and you can kinda follow it from there. So, yeah.
[00:36:49] Unknown:
Do you guys ever see yourselves, at any point, if the prompt toolkit support evolve sufficiently dropping readline entirely and switching to a 1 1 input model shop effectively for crunch?
[00:37:03] Unknown:
So I would say no, as much as I love the prompt toolkit. But but that's only because I want conch to be, available to be used effectively only on the standard library. Right? So that's the only dependency. And the reason for that is because a lot of people are really concerned about portability. This is something that I I've sort of discovered after putting this out there was that, you know, some of the feedback that we were seeing on Reddit and Hacker News and and places like that was that it's a cool idea, but no 1 will ever use it because Bash is everywhere. And so, I mean, while there are tools like Conda and PIP and, you know, getting to the package manager like, the the distribution package managers is really important.
To have that ability to just say, like, okay. Here's my here's here's Python, the Python standard library, and here is my 1 project, and I have a shell, and I think that's that's extremely valuable. So, if prompt's code toolkit can make it into the standard library, then yes. And prompt toolkit probably should be in the standard library once it once it becomes more stable.
[00:38:22] Unknown:
Very cool. So do you have any suggestions for people who may not have the privileges to set their own login shell, but who wanna try conch?
[00:38:31] Unknown:
Yeah. So, I would download and install a conda, version for the Python 3, and then you can say you're forced to use something like bash, or z shell. What you can do is as I haven't tried this, so it might not work. But, I'm pretty sure you can just having installed consch into user space with conda or, you know, with setup dot pie install dash dash user, you can then just have it run consch run-in your bashrc. I'm pretty sure that would work. Or you can just run it first thing, and then you're gonna be immediately dropped into, into a conch environment.
[00:39:17] Unknown:
And would that work better with just running Conch as opposed to, say, exacting? Like, I know in the past, some people when they when they wanna sort of break out of the shell, they're forced to use they'll exec the other shell and then that becomes their shell. But because of all the capabilities that you guys have that sort of, like, peer and interface with bash, does it actually make more sense to just run conch as a user space a regular user space program as part of your regular bash initialization?
[00:39:48] Unknown:
I don't think it much matters whether you whether you run it or exec it, because if you're gonna use that foreign shell interface, the first thing Bash is gonna do is or the first thing Concha is gonna do is fire up another instance of whatever shell, you're told it to use and then read in the data there. So you're kinda it's gonna go you're gonna have sort of 3 levels temporarily while you're starting up conch. So you have bash and then conch, and then conch will start up another bash, and then it'll kill that. Right. Right.
[00:40:20] Unknown:
Right. That makes sense. Thank you. My my IT department has us using bash and bash it, which is kind of, like, supposed to be an Omizeish kinda thing, but it it has some frustrating aspects. And so I I would love to try something else. This sounds great. Yeah.
[00:40:37] Unknown:
And so speaking of permissions, 1 of the things that I've run into a couple of times while playing around with Zaunch is that when I was trying to execute a couple of commands, I was getting permissions issues that didn't seem like I should be getting. At this point, I can't remember exactly what they were. But I'm just curious how the Xon shell interfaces with the different permissions models in UNIX.
[00:41:02] Unknown:
So we don't do anything special there, but if you run into those issues, what I would love for people to do, and this is not necessarily come across in the pull request so far or in the issues, but since we have this rich history model, what I'd really like for people to do is to submit issues with the attached history file, you know, somewhere so that that could just be rerun and it could could figure out exactly what's there, and exactly what environment they were they were using. I mean, you know, we just kinda rely on whatever Python does for our permissioning
[00:41:40] Unknown:
stuff. So Okay. You know, what what Python knows about, we know about. Yeah. I'm assuming that the issue came up at some point in the interaction with the subprocess. And I'll I'll I'll try gripping through my history files and see what I can find where I ran into the issue so I can post that into the issue tracker for you.
[00:41:58] Unknown:
Awesome. Thanks. I really appreciate it.
[00:42:01] Unknown:
And so what are some of the most interesting uses of Xonsh that you have seen or done on your own?
[00:42:07] Unknown:
Aaron Muir, who's going to soon be my employee, which is exciting. He's coming to South Carolina as a staff scientist. So at SciPy last year, we, we sat down and, you know, he started just doing crazy stuff like putting in a Unicode shell in his prompt, was 1 of the things that he did. And then another thing that he did within, I don't know, probably 20 minutes, was he he uses max I term 2, and so, he was able to just really quickly and simply pull, images from Imgur and display them right in the shell, and it was probably like 3 lines of code or something when all was all was said and done. You got this scrolling image of scrolling things of scrolling images coming across the screen in conch, in, like, 2 lines of code or 2 lines of code or something.
That was awesome.
[00:43:11] Unknown:
And so what does the future hold for the XANT project, and how can our audience help?
[00:43:16] Unknown:
Yeah. So there's a there's a lot of things that we'd like to do. So 1 is that we'd like to have native official Jupyter Notebook integration. So there's a pull request in right now that deals with that. But, really, it needs people to bang on it, and there's some issues on Windows and and things like that. So if anyone wants to help there, that'd be great. Being competitive with a lot of the nice features that other alternative shells have, would be would be awesome. I mean, these are things that we're really in favor of. So, you know, the big ones are man page completion, like like in Phish.
Z Shell has a couple of pretty interesting, ideas in terms of, you know, like, oh my Z Shell and the way CD works in z shell is kinda cool, actually. It does sort of pattern matching on your current directory. And sort of so those kinds of extra features that that don't exist right now, and, you know, just getting it out there and getting more people to use it and and to bang on it. And and, of course, the the completion, having a full fully Python interface full Python interface for writing your own completion routine so that you can write your own command. Or you could write an alias, that might use our parts under the covers, and then you want consh to be able to complete on that as well. And so that would be something that would be nice to do and nice to have an interface around.
So I think those are the those are the kind of the big things for now. You know, people kinda ask about legacy Python support, and I'm not personally interested in that. But if someone were to come along and rewrite the parser in Lexar and make sure that everything works in Python 2.7, then I'd probably merge in the pull request because there's no reason not to. So, I mean, there's there's a lot of cool things that people could do, and I'm very open to to contributions. So and and interacting with other tools in in a nice way. And when you say integration with the Jupyter project, I'm curious
[00:45:43] Unknown:
in what direction you're referring because I know that there is a Xonsh kernel for the Jupyter notebook, but I'm assuming you're talking about it the the other direction.
[00:45:53] Unknown:
No. So yeah. I mean so it actually, it is the kernel. So someone out there, or I think actually a couple different people at this point have created their own, kernel wrappers for Jupyter, for Conch, but most of those relied on external infrastructure, like like a metakernel kind of thing. Mhmm. And they end up running in sort of, you know, and that's just like an extra layer dependency layer that I don't want people to have to worry about. Ideally, if you have Jupyter installed, and then you install Conch, you should just get the Jupyter kernel, for Conch for free. It should be part of the Conch project, without any external dependence.
Understood. That that's the pull request that we have in right now. Okay. That it would be really nice for people to to bang on and give feedback.
[00:46:53] Unknown:
And so before we move to the picks, are there any questions that we didn't ask that you think we should have or anything that you wanted to mention? No. I just wanted to thank you guys for having me on the show. It's really great. Yeah. We appreciate you joining us. It's a very interesting project, and I've been having a lot of fun poking at it and playing around with it. And I definitely think that it's going to continue to be my default terminal where I was using Zeech for a while, but I think that this is going to take its place.
[00:47:22] Unknown:
Awesome. Yeah. This is what I like to hear. So
[00:47:27] Unknown:
Okay. So with that, we will move on to the picks. And my first pick today is going to be the SQLAlchemy library and the Alembic migration library for it. Because between the 2 of them they just make interacting with databases so much more pleasant than a number of the other ORMs I've dealt with, particularly the migration capability. And being able to automatically generate migrations based on changes to the model files that you create is pretty amazing. And the work that Mike Bayer has done on that over the years is top notch. My next pick is a movie called Mordecai with Johnny Depp. And it's just a really interesting, quirky movie that's got a bit of a different approach than a lot of other major movies that have come out recently. So I definitely enjoyed watching that. Definitely highly recommend that people check that out.
And for my last pick today, I'm going to choose population. Io. It's a website I came across recently that just has an interesting way of interacting with a lot of statistics around population. So you put in your birth date and it will say you are the nth number of person alive today and you are older than this number of people and younger than this number of people. And based on statistics in various countries, you can see what your average life expectancy is going to be and various other statistics of that sort. So it's just an interesting way of exploring that data. And with that, I will pass it on to you, Chris.
[00:49:02] Unknown:
Thank you, sir. My picks today are science fiction themed because I had a science fiction themed weekend. The first pick is a book that I've been reading, by Scottish science fiction author, Ian Davis, I believe. I might might be screwing up his last name. But in any case, he wrote this series of novels called the Culture novels, and they are really neat. They are vast in scope, and the culture is this expression of humanity where as opposed to the most science fiction novels where technology has taken over and we are mere slaves to computers, this is absolutely not that at all.
Our technology has indeed advanced to incredible extents, and we have created machines that are now autonomous beings onto themselves that, you know, a given person who would effectively. But humanity has not been reduced to the subservient role. It's it's a very symbiotic relationship and humans are, you know, are do what we're good at basically. We use our intuition and our instinct and our and our cunning and problem solving, in in really sort of organic ways. And the humans and the machines work in a really interesting kind of, partnership, and there it it's this is all sort of set against this really large, you know, again, wide scope intergalactic, civilization. It's it's just it's a really great novel. I'm only about 3 quarters of the way through it, but I I love it, and I it's it's definitely pick worthy.
My next pick is a movie, but it I'm also it's a book movie combo. I know this is kinda mainstream and and that you would have to live in a cave to not know about it, but I just saw The Martian yesterday, with Matt Damon as the lead role. And I had read the book months ago and loved it to bits. And, man, this is 1 of my favorite book adaptations from a, you know, from a science fiction novel into a movie. It's really faithful to the book. It's beautiful because it's a Ridley Scott film. The the special effects are just gorgeous, the, you know, the the surface of Mars, and and it's just it's a great story. It's accessible. It's the kind of thing you can take your parents or your, you know, or your kids or your maybe not young young kids, but your kids or your relatives too. It's just it's it's a great story. I'm I'm really pleased with what they did with it. They didn't they didn't skimp out on any of the any of the technical aspects or the technological aspects. It, you know, the the main Matt Damon really lets his his nerd flag fly freely, which I think is really kinda neat.
So definitely 2 thumbs up on that 1. And my last pick is also a movie, going sitting the way back machine for 1973. It is a French surrealist science fiction film called Fantastic Planet. And I was lucky enough to have my local art movie house here in Boston, the Brattle Theatre, played it this this Saturday evening at 11:30 show. And it is such a wild ride. I it defies description, but it is artful and creative and interesting, and has a really surprisingly cogent plot and storyline for all of that. It's definitely worth digging up and seeing if you, you know, especially if you can find it on the big screen. Also highly recommended.
It is in French with subtitles but they're very readable. It's, you know, and it it definitely is 1 of those sort of mind blown kind of movies. And that's it for me, Anthony. What do you have for us?
[00:52:40] Unknown:
Yeah. So, I think I'll just stick with, probably my favorite book, which I read actually last year, but my brother just, just read it and finished it. He he loves it. So the the book's called The Worst Journey in the World, if you've never heard about it. It's sometimes said to be the greatest true adventure novel or story ever told, and it completely lives up to that. It's about the 1911 through 1914, Scott expedition to Antarctica, and it it was written by absolutely Cherry Gerhardt, and it's just it's it's an amazing story, and, even more amazing that it's all true. So definitely definitely check that out. And, I think, yeah, I just wish for everyone who is affected by the flood here to stay safe and dry.
[00:53:38] Unknown:
Alright. Well, we really appreciate you coming on the show and joining us to talk about your work on the Zonsh project, And also just for everybody who's listening and hearing us pronouncing it different ways, if you could just care to explain the proper pronunciation or lack thereof.
[00:53:53] Unknown:
Yeah. So there there is no proper pronunciation of, of of Xonsh. So, yeah, I mean, that's part of the joke. You know, it's 1 of these words that's kind of like a character from a Tolkien or George RR Martin book, you just don't know how to say it. So I often will say conch, but sometimes I'll say zhan, sir. The the weirdest 1 I ever heard was, which I don't even know how they got that, but, you know, have that, say it what you will. It's meant to be written. And how did you come up with the name? Yeah. Okay. So there's obviously the shell, which is, you know, the physical animal, the snail, which is normally pronounced conk, but oftentimes in English, it gets pronounced to conch, although that's that's much more modern.
And then the, the so if you spell that out phonetically, you get, you know, c o n s h, and then the x o comes from, rather than a the c o, comes from a text editor that I wrote about a year before I wrote the, the conch shell. And so the text editor is called XO or Exofrills, and sort of come from the same idea where what I want in my tools is for them to get out of the way and to not have a lot of frills or things that I don't wouldn't expect, and to just let me get straight to the to the code or my task at hand. So that's where the names come from. Great.
[00:55:41] Unknown:
Alright. So for anybody who wants to keep in touch with you and follow what you are up to and what's up with the Xonsh project, how would be the best way for them to do that?
[00:55:51] Unknown:
Yeah. So just, just go ahead, and, you can find us on, we have a mailing list at Google Groups. So it's conch@googlegroups.com. And then so there's also the the website, which is just conchx0nsh.org, so you can visit us there. Or, you know, you can there's also an IRC channel that I'm not on as often as I should be, but other people are, and, you know, you can find us on GitHub and, you know, just send us an email or find find me personally on Twitter. We don't have a Twitter account for the project or anything. So, yeah. And I'd really like to thank, all the people who, have have helped out with the project so far.
Particularly, Adam Hartz came in, and he just did a ton of work early on. We would be nowhere near at our capability level that we are now without him. And then Morten and Anna and and, and some other people have have, have come in, and, of course, the users are have been there, giving us feedback and and helping out. So, yeah. Let's and, please, anyone who wants to help, you're you're more than welcome. We we love slash need contributors. So
[00:57:17] Unknown:
yep. Well, thank you again, and I hope you are able to stay dry and enjoy the rest of your day. Thanks. Thanks, Tobias.
[00:57:25] Unknown:
Thanks, Chris.
Introduction and Announcements
Interview with Anthony Skopatz
Anthony's Background and Python Journey
Introduction to Xonsh
Transitioning from Other Shells to Xonsh
Xonsh Features and Capabilities
Handling Bash Functions and Virtual Environments
Prompt Toolkit and Readline Integration
Interesting Uses and Future of Xonsh
Closing Remarks and Picks