Python Poetry in 8 Minutes

As soon as you start writing more complicated Python scripts , it becomes really important to properly manage your dependencies .

You're going to use a bunch of other libraries and packages and you want to make sure that you have the versions right ?

Commonly used to to handle dependencies is poetry , which is what I use for most of my part , different projects and next on handling dependencies .

This can also do other things such as creating virtual environments for your code to run in , but also publish your code , your packages to Pipi .

So today I'll walk you through the basics of poetry and give you some tips and tricks for how to set up and manage your project effectively .

Before we start , I have something for you .

It's a free guide that teaches you how to design a new piece of software from scratch .

You can get it at Iron dot Code slash design guide .

It contains the seven steps that I take whenever I design a new piece of software .

And hopefully it helps you avoid some of the mistakes that I made in the past Iron dot Code slash design guides .

Link is also in the description of this video dependencies in Python have been handled in different ways .

The past one very basic way to handle dependencies is just Pip install whatever you need in your global Python installation .

That's not a really great way to go because that means that you may have version conflicts .

It will also be hard to keep track of when you want your script to run somewhere else .

What dependence you actually need to install .

So it makes sense to at least have some representation of what the dependencies are supposed to be as part of your Python project .

Common way to do that has been requirements dot TXT , but it's easy to misfigure and kind of hard to update .

And that's why since the 518 the P project dot tomo file has been introduced here .

You see an example of what such a file might look like .

So it has various sections .

So there are general package settings like the name and the version description you can refer to read me file .

There are dependencies .

In this case , we have a Python 3.12 dependencies and you also have built system settings by putting all of this information into a single file .

You don't need a separate requirement dot TXT and a setup dot P I manifest and other things , it's all in one tool file .

Now , you can in principle directly edit this file , it's a text file .

So you can just add your dependencies here , but it's kind of cumbersome and it's in my opinion , better to use a tool like poetry to handle that automatically for you .

For example , if I want to use poetry to add a dependency on pest , I can simply write poetry , a pie test .

And now you see it has installed a bunch of different things .

And if we open the tomo file poetry now has added pie test for us .

And on top of that , it has also installed other packages that Pie test depends on .

And if you type poetry show , then you can see the packages that it has installed , including the version .

So this you can run at any time to see what is the status of your dependencies .

The first time you add a package , poetry also creates a poetry dot log file and this is what that looks like .

Now this is a file that you typically don't have to edit yourself .

It's really an internal file for poetry to keep track of the dependencies .

Next to just adding a dependency .

Poetry has other options as well .

You can also remove dependencies or update them to the latest version using semantic versioning .

Let's explore this a little bit more poetry .

A it is used to add dependencies like I've just shown before .

So for example , let's say I want to add the requests package which is quite commonly used for HTP request .

I can use the ad sign to specify a specific version , for example , 2.12 0.1 .

So when I do this , now it has added request version 2.12 .

And you can also see it's here in the list .

And when I open the by project file , you also see that the request package has been added here .

And as you can see it has installed this specific version .

So if I want to remove the seat , I simply write poetry , remove request in this case .

And now it has removed that particular dependency .

Now , typically I don't install specific versions of packages .

I just want to give some sort of limitation to how we want the upgrade process to take place .

So what I typically do is install the package like so and what this character does is that it installs the most recent version following this version up until the major version .

So it won't install a request version three for example .

But as you can see , it goes up to 2.31 0.0 .

So it's a minor version and not a major version update .

And when you look at a project file , you also see that it has added this specification to the version number .

Now , if I type poetry show and I can even add these specific package that I want to show , they see it shows the name of the package , the description as well as the version that's actually installed or just write poetry show to show everything .

And they will see it as the request package at 2.31 0.0 .

Let's remove that dependency again .

So another alternative is that we add requests using the tilda and the tilda is a bit more restrictive in that it only installs the package up to the latest minor version .

So you see here , it has installed 2.12 0.5 instead of 2.12 0.1 but it doesn't switch to 2.13 .

So basically what you do in both of these cases that you sort of define an upper and a lower bound .

And when you're just starting out with a new project , you probably just want to add the latest version of a package .

But it's helpful to know that this gives you some control over what dependency version you're going to use .

What I'd recommend you use when you install dependencies is the carrot that to me is good , sweet spot between having maintenance overhead and having no control whatsoever over the versions .

And by the way , this is also what poetry does by default .

So for example , if I add fast API , then you also see if I look at the Piro Thermo file that it actually uses the Carrot character by default when you have a P project file , and you simply want to install all the dependencies in it , you write poetry install and then it's going to simply install all of the dependencies .

So you see there is in this current project , no specific folder for this particular package .

So you can also say that there is no root folder and then you don't get that error but it does install dependencies in both .

Now , when you have the dependencies , install poetry , you can also create a virtual environment for you within which you can run your code and you simply write poetry shell to go into that virtual environment .

And then within that environment , you can simply run your Python script .

So it's really easy to use in the vs code term .

You can actually see which virtual environment you are in .

And in this case , in my recording folder , it has created a dot VM folder that contains all the information related to the virtual environment .

Now , poetry also offers some help with versioning building and publishing your package .

So currently the version of this package is 0.2 0.0 .

But if we want to bump the version number , we can simply write poetry version minor and this uses semantic versioning to go to the next version .

So this goes from 0.2 0.0 to 0.3 0.0 .

And this is also reflected in the P project file .

Normally the P project file is something that you commit in your G report story .

So that the latest version number is also available there .

Now there are other things you can do related to semantic version like 1.0 0.0 dash alpha one or release candidate .

There's lots of things to cover .

I might do a separate video about semantic versioning if you like me to do that .

Let me know in the comments .

Now , when you are ready to unleash your project into the world , poetry can also package your project into distributable format such as a wheel or a source distribution TG zip file .

And then when you're done building , you write poetry , publish and then supply your pipe credentials and then you can publish it to pipe .

And of course , all of these things you can also do that in , let's say a github workflow .

So that whenever you commit to a particular branch that's automatically going to run this task or whenever you publish attack on github , lots of possibilities there to automate things and simplify your life .

So I hope this gave you a quick idea of what you can do with poetry .

Highly recommend you start using it .

Now , if you want some inspiration , some ideas from nice Python projects , you could work on to improve your skills .

Watch this video .

Next .

Thanks for watching and see you soon .