 It's funny to see different people pronouncing this project differently, and we have quite interesting stories, we can talk about them. So the pronunciation, please check, or Slovak is tot, and we will talk about tot's open database for Python developers. Before we start, my name is Fridolin, and I would like to ask if there are any Python developers, or somebody who tried Python. Okay, I see some hints. So we will talk about Python, and first we will introduce what tot is, why it was developed, and I will also talk about a team that is behind tot. Then we will do live demo, and I will show you how tot can be extended by your contribution, so anyone can contribute to tot and use it. If time allows us, I will talk also about security and give you some references. So tot started in 2018 as a research project in the office of the CTO that was, or team AICOE, that was AI team in the office of the CTO. It's expanded, and it's now pretty large. If you are interested in it, we have YouTube channel where you can browse videos and content that we publish regularly, and you can also follow projects on Twitter. It's tot station, Twitter handle. The main mission behind this project was to help Python developers and data scientists to create and ship healthy Python applications, and the project itself has multiple parts. We have also collaboration with Pulp team, and in this talk I will focus on tot resolver that is the second item in the listing, but feel free to browse other parts that might be interesting. Okay, so first let's take a look at Python cloud resolver and why it was developed. If you experienced something with Python, you probably know PEEP or PEEP pamph poetry, these are basically resolvers that resolve application dependencies, so you can type PEEP install flask and PEEP will automatically check what flask versions are available and will bring flask into your environment so you can develop some flask application. If you take a look at the last bullet, you see tot, that's the project that's pronunciation is different and hard, but basically the main idea behind tot is that latest software is not always the greatest choice, so sometimes you don't want to install the latest flask version available because it can have some bug that is not fixed yet or it has some performance issues in your environment and things like that. So if you take a look at architecture, it's different from the resolvers that were mentioned, PEEP and poetry resolve application dependencies locally on your machine, but in case of tot, you send application requirements to the cloud, then there's something happened and you get back application dependencies in a form of log file, so each package pinned to a specific version together with justification why you should use that specific package. Under the hood, there's sent more information, so information about your operating system, hardware or static source code analysis, and this all helps tot resolver to select package versions based on your runtime environment, that fit your runtime environment, and tot's cloud resolver uses knowledge about these Python dependencies, so it can resolve really high-quality application dependencies. Okay, so if you're interested in tot and you would like to try it, we provide tutorial that is called Managing Security in Python Applications with the tot cloud Python resolver. It's a tutorial that will guide you through steps required, how to set up your environments to run tot or contact tot and use it. If you start with this tutorial, you will be first setting up your environment and you will need Tamos CLI. Tamos is a command line interface that knows how to contact tot backend, knows how to send that information to the cloud, wait for the resolution and then knows how to, for example, manage your environment locally and install dependencies and things like that. Okay, so now let's go to demo part. As mentioned, there is that tutorial and it links to a repository that is called CLI examples that repository lives in tot station organization and that's basically what I will show now. So first, we will install Tamos. It's already installed in my environment, but you will see that now we have environment ready to talk to tot. If you take a look at repository content, we see that there is some application that is called game of life and that's the application that we will run. You can also see PIP file that states application dependencies. It's very simple application, so there are just few dependencies. We are running Python 3.8 and what we can also check, we can check tot's configuration file. Tot can automatically generate this configuration file for you in your project directory and it basically states inputs to that recommendation engine or to the resolver so that it resolves application dependencies specifically for your environment. Tamos config automatically generated this configuration file. It automatically detects what or how your environment looks like. So here you see CPU, GPU, I'm not running any GPU, what version of Python I'm using and also any additional dependencies such as Open Blast if you run some data science applications or machine learning applications. So this is the configuration file. You can adjust it by hand or keep the automatically generated one. And what we do now is we can call Tamos Advice and in this case Tamos collects information from the configuration file, sends it together with information about your application dependencies and sends this information to the cloud. The resolver does its job and here you can see information that is provided by the resolver. We can see two tables. The first one is application stack guidance that is some generic information and suggestions. For example, that I should use version range specifiers because that's a good practice or information that some packages were removed because they have known issues in the runtime environment that I'm using. Then you can see the second table that is recommended stack report and in this table you can see information per package. So here you see, for example, information about package click that is used in my application and also some security related adversaries. For example, Pillow in this version has some CVE. So I should be aware that there's some security vulnerability in my environment. If I'm fine with that, I can install dependencies and run my application. But let's say I'm not fine with the security, these vulnerabilities that are present. So what I can do, I can ask once again to resolve my application dependencies but this time without packages that would introduce some security vulnerabilities to my application. So once it computes results, you can see now I'm running some Pillow that doesn't have that security vulnerability and in this table you can also see which versions of Pillow were removed because of CVE that was present in them. Okay, so now let's do Tamos install. In this case, Tamos creates virtual environment for my application, installs dependencies and once these dependencies are installed, I can run my game. I will silently pass no pedantic, that's because I'm not running Fedora as in the configuration file and now I can see our game. So I can play Game of Life. So here you can see AI. Okay, so that was our demo just to explain that no pedantic if I would run it this way. My operating system configuration does not match the configuration stated in Totsiamo configuration file so that's a check that is done because I'm running Ubuntu instead of Fedora. So that was our demo. You saw a lot of information. You saw these two tables. They provided information about packages and also runtime environment that I'm using. Now let's try to extend knowledge about these packages that we consume and try to provide a way how to enhance the resolution process so that we get high quality dependencies. The whole resolution process is modeled as resolution pipeline. This resolution pipeline is made out of pipeline units and basically they accept inputs. Then during the resolution each package goes through a pipeline that is constructed and there is implemented reinforcement learning algorithm based on TD learning that selects the most appropriate versions for your application. So now let's try to check how these pipeline units are implemented. You can implement them directly in Python. In that case, you provide implementation in resolver code base but you can also use declarative interface that uses YAML files to describe how the resolution process that selects specific packages should look like and what actions should be taken during that resolution process. This declarative interface in the form of YAML files is available in prescriptions repository that is available in totstation organization. Anyone can contribute. You can see these YAML files as YAML files that are used in Kubernetes or OpenShift that describe desired state of a cluster. In this case prescriptions describe how the desired resolution process should look like. We can take a look at this database. So here you see totstation prescriptions. You can also look at the documentation which will explain how you can write these YAML files and how you can benefit from this concept. And we can quickly check, for example, some prescriptions. As you can see, the directory structure is pretty large. You can find prescriptions specific to some packages. So for example, we can check prescriptions for machine learning library that is called TensorFlow. And some prescriptions are automatically generated by bots. But some prescriptions are provided by users. So for example, we can take a look at this prescription that states that if TensorFlow in these versions is going to be resolved, then together with H55 that is another library, it's a dependency of TensorFlow, there's no issue like these two libraries cannot be installed together because TensorFlow maintainers did overpinning issue. And in that case, TensorFlow as a library does not behave correctly. So this prescription basically heals application dependencies and makes sure that compatible versions are resolved. Another example can be the pillow inversion 830 cannot be installed together with NumPy. This is a known issue. It's reported upstream. It was spotted after pillow release. And when you install these two libraries and you try to run the application, you get this error. So again, we can provide a prescription to fix it. And anyone who uses TOT will not need to debug application, will not need to check what's wrong, why application crashes. But the recommendation engine, the resolver will make sure that correct libraries are resolved. These examples were on Python level. But TOT resolver can take a look at, for example, Python interpreter version that you are using. You can also specify requirements on CUDA, CU, DNN and other libraries like Open Blast mentioned earlier. You can also write prescription specific for operating system. And if you use containerized environment, then the resolution process can be very specific to that containerized environment and can take a look at, for example, G-Lib C version that you have installed or other RPMs. So we are fixing, basically, this known XKCD when you have one small package in your wall infrastructure and it breaks. I think there were pretty nice examples, especially in NPM world when things were broken because of maintainers, maybe from Nebraska. Okay, so we have some time left. TOT can also guide you with respect to security. Like, originally, TOT was called AI DevSecOps. And it accumulates information from various sources and can guide you with respect to security. So if you take a look at our output that was produced by the recommendation engine, you can spot, for example, information about pinned dependencies. So if a project uses pinned dependencies or if it honors some best practices or if there's branch protection made. These information are aggregated from a database that is provided by Open SSF. And this organization basically accumulates information about open source and TOT automatically ingests this information. TOT also gathers information about CVE. That was a thing that we've seen. So for that purpose, we use advisory database, which, again, is a database of known vulnerabilities. So you can see packages and, again, YAML files that declare CVE information for Python specific packages. This is a database directly maintained by PyPA. And if you use containerized environments, then you can benefit from scans that are done by Quay. And we aggregate information about RPMs and known vulnerabilities on the RPMs level. Okay, so if you are interested in TOT, feel free to browse our web page that is totsstation.ninja. You should be able to find more information, also linked demos and tutorials that we provide. And here are some references. So if you like to read and dive into technical details, we provided a few articles and series about TOT's resolution process and why certain technical decisions were made and why you could use TOT. TOT is an open source project. API endpoints are available to the community. So anyone can use it and anyone can contribute knowledge about Python dependencies or Python applications text so the whole community can benefit. And this way, I would like to thank you. And if you have any questions, feel free to ask. Sorry? Why Pyramids? Why Pyramids? So TOT is God of Wisdom. It's an Egyptian God. But it's also TOT Station. I think it originates Star Trek. Is it Star Trek? Or what is it? It's some TV show? TV series. And if you want to check our endpoints, they are available in Kemenu. That's some starship, if I remember correctly. So we were really picky when naming things and it creates a lot of fun. Any other question? So the question was where you can find our slides or these references that were in presentation. We did talks on different conferences, DEF CONF mini including. And here you can find slides. It's TOT Station slash TOTS. So TOTS repository in TOTS station organization. And I pushed 33 minutes ago these slides so you can find them here with all the references. And they should be clickable. Maybe when you download it. Yes? So the question was if we would like to support other language ecosystems, right? That's a good question. TOTS, as of now, is very specific to Python. But these ideas like prescriptions, the resolution process or cloud-based resolution process could be adopted to other language ecosystems. I think NPM is very nice candidate. But as of now, the whole infrastructure is written in Python. There are parts that are written in C++. But the core infrastructure and also the resolution is very specific to Python. So if there are volunteers to extend, I think it could be very valuable. Are there any other questions? Okay, then. Thank you. Thank you.