Transcript: PyCharm - Paul Everitt & Aleksei Kniazev

I'm Carlton Gibson joined us ever by Will Vincent.

Hello, Will.

Hello, Will.

So we're gonna talk everything PyCharm and Django and all such things.

Hi guys, thanks for coming on.

Hello, hello.

Let's kick off.

PyCharm.

JetBrains is one of the big um big sponsors of Django Cons and uh and big in the um Django community.

Tell us about um PyCharm.

What is it and why should we be using it?

We are not necessarily a text editor.

We try and take all the things that you do and bring them into one consistent user experience that's all supported by us so that you have one throat to choke.

I can't really say that in a podcast, can I?

Yeah.

And uh it's funny, since the beginning of PyCharm, which was a long time ago, 10 years ago, uh it was positioned as the Python and Django IDE.

So the Django support is mature, it's evolved, it's stayed current because people like Alexei put a lot of time into thinking about it.

And before we just dive into the features, can I ask a bit more about JetBrain's current?

Because I go to the JetBrain site and I see PyCharm's just one of the options there.

Is what he's trying to say.

We uh our maybe the biggest one is IntelliJ Idea, that is an ID for Java and Kotlin.

We also have uh IDs for well, Python, Go, uh, JavaScript, uh, as well as plugins for like Scala and Rust.

Okay.

And the point that Alexi's making is it's all built on top of this IDE platform.

It's written in Java, but all the integrations are written with the native language uh participating.

And so what that means is when we have killer git support in the platform, everybody gets it.

So you don't need a git client as well.

So it's a literally everything.

It says you say it's one throat to chunk.

That's good.

Well, yeah, well, we want to talk about the Django specific features, but maybe if you could just fill out the battery, batteries included, because I know you have database support.

So, for example, like I use Visual Studio Code primarily, but I've also used PyCharm.

What are the I know there's a bunch more that PyCharm does, like just what are the high points of what you know beyond an IDE that it provides as opposed to Visual Studio Code or Atom?

So we have PyCharm Community Edition, which is free and open source, uh, but it's aimed at Python.

PyCharm Professional Edition gets you uh full stack.

Uh we bundle WebStorm, which is our ID for JavaScript, HTML, and CSS.

We bundle Datagrip, which is our IDE for SQL and databases, uh, some remote development stuff, uh, some things like coverage, et cetera.

And with PyCharm Professional and kind of the whole full stack thing, it's we say full stack from a programming language perspective, but we also mean all the activities running, debugging, profiling, uh coverage, VCS, database, all kinds of things into the yes, yeah.

That's a very good point.

Trying to ease the uh onboarding.

Because I know that's challenging for people, and they all said, Well, we're using PyCharm, so it wasn't an issue.

And that was the first time actually I was like, Oh, like I didn't I didn't realize the full featured nature of it.

I was like, wow, yeah.

It's a lot a lot simpler than rolling it your own yourself.

And uh you mentioned academic, it's also free for open source as well, and we have kind of startup discounts.

Um, you know, we're still a human-sized company, and so we kind of act we we we treat people the way we'd want to be treated.

Um, and that's the that's the biggest corporate uh donor to the DSF by far.

That started a good number of years ago.

I think it might have started before I joined Yeah, like right when I joined the company five years.

Um, the previous PyCharm uh product marketing manager, Dmitry Philipov, is the one who started that.

And um it really has raised a good amount of money.

And some things fit people's brains, some people don't fit people's brains.

This seems to fit people's brains.

Um so Carlton's one of the fellows.

That's most of the money goes to Carlton and Marius, who's the other fellow.

Um, and it's generally around a quarter, so it's anywhere between 30 to 60,000 a year the last couple years.

So very material.

We're working with uh Roberto.

Um and what what's the

details of the of the offer?

Well, we're a subscription, and so we hope to see the upsides in the future years if people are happy with the product.

But it is true, 100% goes to DSF.

So as long as we cover our costs for hosting and fellows and conferences, that's that's the goal of the organization.

But anyways, enough about the DSF.

Let's talk about features.

So, can I tell you my my sort of top favorite ones from PyCharm?

My my my absolute favorite one, which is closely related to my second favorite one.

My absolute favorite ones, there's a little down the left-hand side, there's a little structure um button.

And you feel you you click it, and up comes this sort of class diagram of all your you know, your nasty model layout, and it's like, that's fantastic, that's what I've been looking for for years, and you can move around it and you can, and it's even got a minimap.

So, you know, when you've got far too many models and they're all joined up in horrible ways, you can click around the mini-map to navigate.

That's my favorite feature.

My second favorite feature is in the gutter, um down by the side of the editor, you've got this little button about um for, and you click it and it shows you all the subclasses and all the superclasses of the class you're dealing with.

So I don't know, you've got my custom HTTP redirect response nasty thing, and you're like, oh well, I need to see what the the the base implementation.

You just click that and it's like uh here's all the superclasses, and you're like, that's the one I'm after, and you're there.

And that's so those are my that's my favorite and my second favorite feature of PyCharm.

So go on, that's that that that's just an opportunity for you to know how to spin off for 20 minutes and tell us all your favorite bits.

Uh we are very proud of uh how it's actually done in PyCharm.

And what I uh really enjoy is that it can be done uh not only through your just a Python code, but just navigating to your templates from your view for uh to the um to the view function from the template and uh to the variables that were passed to your template.

That's one of my favorite things.

Right.

Essentially we've taught the magical Django strings and conventions to be symbols as if they were Python.

And once that's done, all of our IDE machinery kicks in.

Okay.

That's that's where Django specific knowledge gets handy if you if we know your models, if we read your code and understood it, we can give you like autocomplete for foreign keys, for example, that are not in the in the current model, but might be somewhere somewhere else.

I mean.

Sorry, go ahead, Carlton.

And how are you able to say, oh, we you know, we think we're better in this regard, or we think we're we're better in that regard?

Like, how would I compare the the autocomplete from the two processes?

Because you've got a lot more, like you've you've got 10 years of building the thing.

Yeah, true.

Um, but I still think that we're somewhat ahead in this regard.

And uh we try to evolve, of course, and uh having uh 10 years of uh Django support uh in the in the ID it sometimes it's it takes some work to how to say it better.

Well to to make it work with the new features okay.

And uh we we adapt and evolve, and in fact the imminent upcoming had basic yeah, had a basically uh full-time pie charm person, Lada.

And so, like total rethinking of the experience for typing a couple of characters and getting a deeply nested import generated for you, which is pretty badass because I hate stopping what I'm doing and going and typing my imports, just hate that.

Um, but just in general, uh, it's fun to see the rise in smart editors.

It's fun to see the rise in Python providing more information to help smart editors.

Whether it's fun to see machine learning giving suggestions for you is I'm an old get off my own.

I know what code is.

I I gave a talk at DjangoCon the last one two years ago on search, and the problem is everyone assumes Google is the baseline, and Google's a pretty high bar.

So like it's like when people complain about search, I'm like, why don't you try building your own search?

And then you'll start to see, you know, exactly as you said, it's like teeing up the right one is is quite challenging.

But but you know it when you see it.

And I thought this is gonna be great, it's transactional.

And they're like, no, it sucks.

It does search, it just doesn't do it astonishingly.

Yeah.

This is something I've been really impressed by PyCharm, the integration there.

So I um and specifically Docker.

So like in one of my books, I use Docker because it is challenging to set up Postgres in particular on Mac vs.

Windows, and people get that wrong all the time.

Can you talk a little bit more about the database integrations in PyCharm specific to Django?

And um Yeah, so this is bundled in uh PyCharm Professional together with Django support.

And once we uh have the connection to your database, once we know where it is, it's actually uh so we can provide you suggestions for, for example, for your column names, we can uh highlight your SQL queries and stuff like that.

You could be you can be typing a SQL string, or as Alexei said, working on a model, you can navigate to the column, you can sit in your Python code and rename your column, and it will go and actually change your database.

Uh you can it execute a SQL query right in the middle of your Python, it'll open up a panel, a console with the query results.

Um and maybe Will, your question was what can it talk to?

It's JDBC.

So, you know, most of the most anything that has a JDBC driver, which now includes MongoDB, uh, we can provide this experience with.

I mean got secret source there, I don't know.

Um but it's one of the hard bits to, you know, when you get into advanced queries, it's one of the bits that people struggle, and you have to spend a bit of time, you have to spend a bit of thinking about how do I craft my query set exactly to get the the this the SQL that I'm after.

So outside of PyCharm, what's your way to visualize it?

And I I see, or I go query.query, and I get the the the generated um SQL string.

And it's fine.

Yeah, it works, but it's not but it's not smooth.

It's it's a

bit Carlton.

Do you think that string that's being generated is all the information available statically from static analysis?

Or does it require some kind of runtime thing?

I'll bet it is available from static analysis.

It's the parameters that you need.

But like, you know, when you once you've got the model defined, once you start filtering and you add on the columns or you add the annotation, the the actual compiling

Wouldn't it be cool if you could do alt-enter and convert a SQL uh uh ORM query to a SQL string?

I'm thinking how we can implement this.

Okay, so it'll be out by the time the podcast is like good.

Is uh it's one of the more difficult bits of Django.

Is when you're crafting these complicated ORM operations and you've got a nested subquery, and then there's a window expression, and exactly, you know, when I if I if I add in that rank function, then what's what's it gonna start producing?

It's like to see that live, that would be you know, that would really change the game, I think.

To sort of be able to iteratively build your query set calls.

Okay, now

We have internal hackathon contests.

That's really kind of where most of the focus is on is figuring out how to optimize them, how to craft them.

Um, all the kind of the rest of it, I would say, is not as advanced.

Or you I I don't know.

That's that's my take.

Like model, you know, models are models, views, templates, URLs, it's a little bit of whatever, but like the query set is kind of where it's all at once you get beyond a prototype, I would say.

But I like sweeping generalizations, so yeah.

It's true.

There you go.

So sure.

How about giving me some help on the hard stuff?

There's the the beginners for whom if they have access to Python, which I guess they do if they're a student, it's solved so many problems.

And then there's that middle ground, and then there's the Carltons who are like, yeah, these advanced features.

I suspect those are the two barbells of where you kind of focus.

Is that accurate?

And the uh Python developer survey that came out recently showed that um there's a question about how long have you been using Python?

And the answers were like, I don't know, under six months or a year or something.

I was like, you know, because I was sort of it almost made me um not discount the results, but realize how many new people there are in the space.

Because there's a lot of other questions about your you know preferences as a professional.

It's you know, it's a whatever a third new people.

You know, we actually that that Python survey, Django did our first survey in years last year, um, really modeled off of that Python survey.

We're gonna do it again this year.

So actually, if you have any suggestions on what we ask around IDEs, um let me know.

Sure.

Because we'd love to, because we don't track anything really about Django.

So the survey is a way for the you know fellows and the um technical people to to kind of know outside of Django cons and message boards what we should focus on.

Yeah, we can do that offline because we had we had thousands of responses, and it was literally a Google Doc I set up.

Yeah.

So we could do better.

Um uh in regards to kind of that bumbbell dumbbell thing that we'll uh Will was just talking about.

Um in looking forward forward to the rest of your year when it comes to Django, do you think your activities will be more about beginners or more about advanced?

So uh we plan to uh uh to do some work enhancing the possibility to view Django documentation uh from inside the PyCharm.

Yeah, we we already have this possibility and I really like this feature, but it's it's kind of obscure because you have to enable it specifically in settings, and we don't promote it much yet because there is some work to be done.

But when it's finished, I think that it's gonna be pretty good because we have the ability to go to your uh uh cross hierarchy or to a symbol like in your settings file and uh check the documentation that comes straight from the Django documentation website from inside the PyChar.

And it it doesn't matter where you do it if you do it uh for your views or for a string in your settings file.

Because and for the particular version of Django in the in the in the virtual environment.

So I'm running, you know, on this particular project, I'm running 2.2 point whatever.

I've I've got it.

Yes, I can pull the the documentation for 2.2 point whatever, and I can have that demonstrate.

I mean, so I use Dash, which is I think just an awesome thing, and I have you know, I have it open all the time for documentation.

Um, but one thing it doesn't do is allow me to version by project, right?

I've got it's always got the latest one, but sometimes I'm not on the latest one.

I need to see, and so I have okay, I have to go to the website, and okay, it's not the end of the world to have to go to the website, but it's not you know right there and then.

So if you could pull it locally and build you know, run Sphinx and

I mean, yeah, if you index if you can index properly and pull out all the those annotations that get you right.

I I know I'm looking at HTTP response.

Well, where's the docs for that?

Yeah.

Yeah.

Because you know, beginners they're too scared to look at the docs.

They don't do that.

They, you know.

So there's there's they go there to be confused and then they come to my educational stuff.

But I think that is valid, right?

I mean, because I've thought a lot about this.

Like, should I what is the difference between the two?

And the difference is docs are designed for, you know, Carlton has a question or I have a question, and we go and see, oh, this is how it's defined, as opposed to a tutorial or a book that says, let me start from the beginning and go through everything.

And that's not what you need if you're you know more advanced.

And it's also so much work for me, it's like hard enough to do my things, let alone that you know, the Django docs are thousands and thousands of pages.

So there's a place for both, I guess, is where I've come out after a number of years of doing this.

What was the because you have definitely two things you were gonna tell us?

So uh sometimes it happens that we have an idea directly tied to Django, sometimes it happens so that uh amazing people that work on the platform level uh have a cool idea to implement across all IDEs.

And in IntelliJ Idea, we got this thing called endpoints, which is basically your URL endpoints.

And um we we have this for Django, like for your URL patterns, but this is so much more powerful when we can know your actual endpoints where your resources are located.

We can we can do navigation, we can do auto-completion, and not just in your Django code, but like for your in your template, in your JavaScript code, anywhere.

We can build uh diagrams of uh how they interact with each other.

So I'm really excited about it.

So, for example, you have two applications that need to talk to each other.

We can uh since we already tied your uh like templates and Python code to each other, why not tie uh different applications that are meant to talk to each other?

Yeah, yeah.

It kind of bounced off me until I saw a demo.

I'm like, are you kidding me?

How do you know that?

How do you know how to want to complete that?

Just uh okay.

Yeah.

Because I wanted to talk a little bit about um so from the IDE developer perspective, talk about um some of the features of Python and then their applications to Django, particularly typing, right?

Because Django is really dynamic to net by its nature and it's really hard for us to throw in um type hints where you're just gonna end up having any all over the place because yeah, uh and at that point it's it's not worth the price of it.

You know, if you've got a nice new thing, it's tight and it's you know, you know exactly the types, then type hints are beautiful.

But something like Django, it's much more difficult.

So what are you obvious?

But yet obviously those give you more static information, which enables you to make the IDE better.

So, you know, riff off that.

How where's the ground and where would you like to see Django go?

And what do you think is possible?

And uh

There is um keyword arguments, there are attributes that are not really declared but added later.

So it's it's really hard to express statically.

Some some some of it might not even be expressible statically.

Uh but we've got a very good type checker that works off of Python, and then it has the ability for us to plug in into that with our specific knowledge of Django and say, like, uh I see you have this function, you have a filtering function here.

Probably this is uh related to this model.

Let's have autocomplete here, let's have keyboard arguments here.

Uh and it it's always easier to do for stuff that is um statically expressible, yeah.

Yeah, but um I understand it's not always the case, and we try to do our best for Django uh where we can.

There is this project that is uh stops for Django, uh which is which is pretty pretty great, and um I'm hoping to one day uh use it for our own analysis to kind of enhance it, but uh so far it it's been kinda hard because uh because of the dynamic nature of Django and because um the subs project is tied directly to MyPy and has it its own MyPy plugin.

So yeah.

Okay.

I'm sorry, I'm gonna go on pull.

Go on, go, go.

You do.

If I remember correctly, one of the first uh motivations for the DSF campaign with PyCharm, the fundraiser, was the money was going to go partly towards fellows and partly towards the static typing uh work.

Yeah, no, this was years ago.

And didn't you know, didn't JetBrains didn't they fund some work on it?

And it's like, yes, but how is it to be done?

But it's hard.

Well, it's not it's not that it's just not possible, but it's a massive undertaking, and you know, it maybe we could smuggle in some bits in the internals where it's more tightly constrained and then you know slowly do something.

I spent a lot of time in the front-end world as well.

Uh do big tutorials on React and TypeScript and test-driven development.

And watching TypeScript happen has been fascinating to me.

If you thought that the Python people enjoyed Lucy Goosey, JavaScript's like hold my beard.

And yeah, TypeScript is now really popular in the front-end world.

But in the beginning, I would read the TypeScript roadmap and I'd be like, okay, first, I don't understand any of those words.

They're using these type theory words that I don't understand.

And second, I would think, okay, that's for Angular.

That's for Angular.

Angular's the only one that has that problem.

Angular's the only one that has that problem.

And gradually they've expanded, expanded the scope of their type system to be able to allow things like Angular and large-scale React things to give a fantastic developer experience statically.

Yes.

Static analysis.

And the world of Python just doesn't quite seem to be in love with static analysis the way that some of these JavaScript people have.

I mean, you know, there are some big advocates, you know, core Python core developers who are very big advocates, but equally there, you know, people who are very big in the Python world who are vote quite vocally against going too far down the road.

Um, I think there's one thing from the PEPS which is um important, which is that type annotations were always meant to be optional, even by convention.

Sure.

Even by convention.

Where it's like, but they're meant to be optional.

And you're not feeling that as a maintainer, you're feeling like, no, they're compulsory and you're falling behind the times by not putting them in.

It's like, oh, hang on.

The peps say they're optional, even by convention.

So I don't know.

It's curious.

The world of Django is what percentage on board with using my pie, adding type annotations?

Um I think using the using the type checker is not as prevalent as it can be.

Because if you're not, what's the point of an annotation if you're not going to use the type checker?

Well, the IDE gives you better order completely.

I sort of need to need it, and then I get all the thing.

Like I was writing some yesterday to see if I could get um autocomplete to work, so I've got you know, it was in a PyTest fixture, and I was returning factory function from the PyTest fixture, and I wanted autocomplete, and he wasn't giving it to me, so I spent you know 10 minutes, 15 minutes writing this annotation.

I still didn't get auto-complete, and I was like, but it's horrible, so I'm deleting it.

Um and I I don't know why.

And where you've got an ugly annotation, you create an alias and then you just use the alias and then it's slightly prettier.

And there are there are things which I do without thinking in these other languages, which I'm I'm kind of reluctant to do in Python.

I think I need to just get over that.

So uh I don't know about in general.

I think it it's coming.

Python in general is is is increasing it, but I mean Django's maybe not the right example because it's got we've got this big history and this big like the core of the ORM.

You you type out you try to type into that, like you know.

I don't know.

Um I would echo what Carlton said when I talk to professionals, it's pretty split.

Some people are really into it, and some people are very wary of it.

If you if you take the time to think what's the type, what's the what's the type that's being returned here?

Oh, well, this is a this is a callable that takes these parameters and returns this, and in fact, it's a it's got a generic variable because I'm using it different times, and if I genericize it, I can create one version of this instead of four, and all of a sudden you've refactored your code because you spent a little bit of time thinking about the types, and it's like, ha ha, that's a win.

You sort of need to have the problem, spend the time, come to the solution, and then you're proselytizing for it.

But yeah, right.

Well, so I have a question for the go ahead, Paul.

Go ahead.

So there's so many features in PyCharm for Django.

How do you think about prioritizing them?

And and when do you readjust, you know, the top three, top five, right?

Because I assume you you s the first question is, well, what kind of programmer are you?

Are you a student?

Are you a professional?

Um, so I guess you know you keep adding features, but you still can only hit someone with like three to five killer features.

What is that process like?

Um, because I imagine that's a challenge.

But um, for one thing, we have an open issue tracker.

So it it's always possible for users that have some have a need for some feature to come up to us and say, hey, I I would like to have this.

And uh we always look at what our users want.

We uh talk to people at conferences, we uh try to find out what the workflows are, uh try to think about how we can actually enhance it, not just by uh because maybe there is a better way that would be um that would include uh this feature in it, but would actually deliver more.

Uh so we have a voting system in our issue tracker.

Uh so that's that's basically it.

So we uh we talk to people, we encourage people to talk to us about what they want and try to stay up to date with what's going on.

Right?

Because you don't want to be sorry, you don't want to sorry to interrupt, you don't want to be AWS with 300 config options, right?

And that's always the challenge, is you keep adding stuff.

It's really hard to take something away.

But if you don't, then it's a bloated mess for a new person.

That's been a challenge.

Um, it's been a challenge for us, and I would argue that it's still a challenge in some areas.

We still have some support uh support for some things that we would probably prefer to take out, and I hope we would in the near future.

Um we usually when we uh remove stuff from PyCharm, we extract it into a separate plugin and uh open source it if it wasn't already open source, so that people who yeah, uh who's uh so that people who still uh would prefer to use it uh can still do it.

Before each release cycle there's a two-headed planning meeting one a retrospective to look back at the previous release cycle and then a uh planning the upcoming release cycle and they actually do produce a list of top tickets with votes and that is an important input to deciding what gets done uh but one of the things we're learning is that we have a lot of features we have a lot of feat

ures right we could probably go and announce new feature in 2021 point one this thing we implemented five years ago yeah and people would probably it would probably probably could get away with that uh

presents itself to you in a subtle non-irritating way at the right moment.

If you're a mature product you you've got to you know you've got to maintain that um I mean you know so this has come up in the typing conversation to just cut back there is we could make the types tighter in Django you know it's meant to be a a string you get here we could say yeah it should be a string and then drop the or any but we can't do that because there are people relying on the fact that you know dark typing works and blah blah blah.

So okay that won't change um I guess the same for if I was developing an uh an IDE what would I think I mean sometimes I still use an editor right so my my other thing that I use is BB edit though.

I have it open all the time and I use it for any number of reasons.

But one is it's it's just an editor and sometimes you just want an editor um I don't know how do you how do you maximize that kind of efficiency zone where you've got the features and you've but you're not you know you're not like flying a 747.

But I think that I mean with Django thinking about extra features I mean we have a very robust third party package system and that whole process of sometimes things can leave Django I mean what is it something recently major left okay

There you know there's no reason why you can't extract um a package as a plug-in that's a great idea you know make it it's still available if people want to use it they can maintain it they can or help maintain it they can use it but you're not forcing it on everybody.

So perhaps we could make core mail a third party package that's a genius I'm doing the Mr.

Burns now

Yeah it's like one of the ones I get all the time is why can't templates do more or why can't there be a front end thing?

And you know it's a logical question for a beginner I think um but it's also it's already big enough.

So the other thing we do is we say you you want a new feature build a third party package and if it gets uptake then maybe we can bring it into core.

So you export features to plug ins you also can I you know say I think I want my own feature and you're like no we're not adding that can I write a plugin for um PyCharm?

Recently we had a poetry support added via third party plugin.

Yeah because same for us that is an right it's just there's so many ways to do it there's still a lack of universality you know Pip M project has an interesting history you know I still use it but I debate it.

's that's a sure sign that something's not going right.

So um yeah so we uh re um started rethinking this whole this whole story so we extracted the uh support for installing packages into a separate uh thing we call tool windows like the thing you get for uh for git or for for your terminal uh we extracted it there with the possibility to browse um the documentation for it and we plan to do much more to

to tie it to your environment description uh like for your requirements.txt file to your Pyproject Tom or whatever you're using so that if you install package via PyCharm you can just uh not care whether it's um properly added into your requirement description um environment description

solve virtual environments if you just had to pick one what would you tell them to do?

So I will go ahead and suggest the failure approach uh there's that pep push by Kushal Das about having a dunder pie packages dunder that's like node modules so that you don't even think of a virtual environment there's no ver there is no concept of that and in a tweet he uh Lukash explained why I'm wrong that edge cases and backwards compatibil

ity and stuff like that but my gosh all of these as a developer advocate all I do is tutorials yeah and they all start with the same thing like here's 50 hours of janitorial work that I wish I didn't have to say.

Yeah.

then there is a 10% case that if you have these issues you go elsewhere but I mean uh Russell Keith McGee you know his keynote at PyCon two two years ago black swans you know one of the two things was we got to solve this problem or we're gonna lose to JavaScript or you know, WebAssembly.

And if there was going to be a Python 4 that had a breakage, and there was only one breakage that could be allowed, this is the one I would break.

Uh, we don't have to support easy install from 2005, you know, some obscure edge case.

And the the learn Python book needs to say this is the thing you have to learn.

And but for Node, it's an MPM install, right?

And although they've got Yarn now, so you know, perhaps it's perhaps it's not.

But I think that's just the case, is that I mean, so I have a site, installpython3.com, and I actually own installpython 4.com, that gets quite a bit of traffic because a beginner says, I don't care, I want it to work.

And so as soon as we start saying the conversation we just had, we've lost them, right?

It's like, okay, just get something working, and then you can learn why it's hard.

But it's really probably not hard if you're just starting out.

Yeah, I was gonna

What so like a personal project, like a green field, you know, you've you wake up, cup of coffee, new Django project.

How do you get things installed?

I I would just give it to PyCharm, like do do this thing for me.

Okay, just

have an interesting question.

Does it does it use VM or does it

It would remember the location of the, for example, .vnv folder that you suggested and use it for your feature project.

Um it would uh detect the one if you're opening your project with the virtual environment.

So uh yeah, of course, uh lots of thinking is going into how we can simplify the uh project setup.

We've uh we've added recently the possibility to install Python from inside the PyCharm.

If you're opening PyCharm, you don't have a Python installed, you can do this.

Uh and it would look virtually the same as setting up your environment.

You can just hit next several times and boom, you got a Python there.

So this is my this is my goal, right?

And I haven't and and you know, it's a basic for a base project, I'll use vmv.

And I'll just use vmv and you know that that's it.

You know, and I'm happy with that.

And pip install with requirements file, and I and I don't want any of these other things because they just they're more trouble than they're worth, right?

But the but then I need to test against Python 3.5, python 3.6, python 3.7, python 3.8, 3.3.9.

I need to test Django 111, 1.2.0, you know, I need to test all these different combinations.

Um, so I use PyM to get the multiple Python versions installed.

And then I use Tox for the to define this nice matrix for all the things, and I just run TOX.

And that's about as close as it can be.

And that what I haven't found is a kind of way of handling that smoothly in the development environment.

So I want to quickly spin up a Python 3.6, Django 3.0, you know, I want to install that one.

And and talks have in have come up with a dev em flag where you can use it to you can say use this environment to create a development environment.

It's close, but it's still not perfect.

And that would be somewhere where I would expect an IDE to step up and say, look, I can manage this matrix and I can help you create all the different ones, and I can activate this one, and I can be a hundred you can be a hundred percent clear of which one on the matrix is activated now.

That's where I think an IDE would pay value over a text editor, you know, where you the text editor's not gonna do that because it's out of bounds.

But that's the sort of extra feature that I'm thinking.

Oh, does PyChum do that?

Because if it does, then it's you know really hard.

I mean, no, not not necessarily yet, but that's what that's my sort of holy grail that I haven't found.

And you know, PipEmv had different it had a dev thing, but it just wasn't enough.

It wasn't flexible enough.

It was you know, yeah.

So for example, if you're for sure, there's a possibility to have several interpreters set up for your project.

You can easily switch between different ones.

That no problem about that.

But what if your uh requirements file is not the same as the state of this interpreter?

Should we suggest to install it everywhere there?

Won't we mess up something something in your next environment?

So yeah, it's it's a really hard question.

It's the one that we're constantly asking, and um I think we try to bridge this gap.

Um what you described is uh is a very good case.

Um we're we're thinking about it, and I think we'll continue to do small steps in that direction.

I'm hoping we arrive there someday.

But the the the one more thing as I want is okay, this is all going great, and I'm I've got my environment set up and all the rest, but now I've I've got a really hard problem to debug, and I want to install various extra debugging tools that I just want to use for now, right?

I don't want them in the virtual environment all the time, but I you know I really need to solve this problem now.

So pip install this, pip install that, pip install install the other, fix my debugging problem, but then my virtual environment's nuked and I have to rebuild it, and in which version, which you know, so the ability to layer on a sort of extra layer of develop of debug tools just for the moment, that would be a kind of you know, like cherry on the top.

Anyway, I I leave leave that with you to ponder because that's these are the things I end up struggling with.

I'll I'll add it to the list.

Oh, sure.

They learned their lesson 10 years ago when they tried to do some big bang effort and it got rejected.

I don't remember any peps about either one of these two problems.

I don't know where you

I'm not right.

I mean, so I think um pyproject.toml has just sort of finally been given the the blessing.

That's gonna be the way forward.

And a couple of years it's been like, well, do we need want to add this to Django?

Is this where it is?

I mean, we just add setup.config and we moved all the stuff from setup.py to setup.config, and now we're gonna move it to pyproject.toml.

Is that gonna be permanent?

Or I think that will be permanent now, I hope.

Yeah, no, right.

I find yeah,

And uh I I stay clear of it for this reason.

I mean we so where so people listening who say, Oh, I've got a great idea, or I agree with that, I guess we can put a link to the issue tracker um for PyCharm.

Is that the best way to reach out to either of you?

Yeah, of course.

The more information we have, the more thing we can provide.

And there's a gener

Sorry, go ahead.

Because I for for ages I I looked at the PyCharm website a few times.

I was like, should I download this?

And then I was a bit scared by the form.

And in the end, I did I click the download button, it was quite easy, and they just booted up and wasn't a problem, you know.

But certainly I think that's starting to change, and certainly for students, you know, when I go into universities, it's overwhelmingly pie charm um over anything else.

Um, in part because you know they can use it for free, but because it does have all these features, and then you know, sometimes I'm not as familiar with all the power features, so I have to sit there and go, huh, I didn't know that.

Like that's pretty nice.

Uh so it's educational for me as well.

I do this all the time because we have so many features that we constantly discover new ones.

I didn't know that.

It's my job.

You know, people say, well, of course you must know this because you wrote books on it, but you know, I just discovered this thing, and you know, like yesterday it happened.

I was like, well, I didn't know that about Django.

I get paid to like be an expert for PyCharm, and I know maybe 2% of PyCharm, and I wake up each day and it changes another 1%.

So don't talk to me about imposter syndrome.

My imposter syndrome can beat up your imposter syndrome.

And so it's just knowing, being comfortable with not knowing, but having the confidence to say, well, I could figure it out.

Sure.

Um, because so when you've ingrained that process of Googling and you have enough context to you know use the Django docs completely, I think that's when you overcome it.

But when you feel like you hit a roadblock, that's where the imposter syndrome smacks people, I think.

And yeah, I'll go to an issue on the issue track and it'll be some nasty in the depths of the ORM, and there'll be two two or three of the major ORM contributors there, and I'll just be like, oh I'm not hanging out in this club.

This is too hot.

But you

When people start when people start asking you questions and you're like, I don't know, you know, that's when you're like, well, I guess I'm at the level of an expert because nobody knows.

But that that feeling of doubt still lingers.

That feeling of like, ooh.

Well, hopefully that's something we do with a podcast is having people on who are experts and everyone says the same thing.

So people listening know that this is just what it feels like.

You know, it's like we just get comfortable with feeling stupid.

And you almost, you know, it's like I almost get bored now if I know how to do something.

I'm like, shouldn't this be a little harder?

You know, like because the muscle is so built up.

Anyways, well, we'll have links to everything.

Um, obviously, you can go down, download PyCharm in April.

Check out the Django Project site for the free trial that benefits the DSF.

Um, and yeah, thank you both for coming on and sharing about PyCharm.

Thanks for having us.

All right, we are at Chat Django on Twitter and DjangoChat.com.

We'll see everyone next time.

Bye.

Join us next time.