 Hello everyone, welcome to this demo that will be demonstrating TOT that is a server-side resolver for Python software packages. And in this demo, I will show you how TOT can give you guidance on the applications tech that you are using when developing Python applications and Python data science projects or anything like that. So I will work in my terminal that you can see. I have just one file present in the terminal that is called app.py. So if I take a look at the content, I can see that it's a brief Flask example, just a hello world by Flask. And normally people, when running applications would use PIP to install dependencies. So if I want to run this example, I would need to install Flask. That's my dependency of the application stack. Another solution is to use PIP-ENF or poetry and basically install requirements of my application. I will not do it this way, but rather I will use another commands that is called TAMOS. And first I will install it into my environment. So what I did, I called PIP install TAMOS. After this, I have a command line tool present in my environment. This command line tool is called TAMOS. You can check its help and information or capabilities that TAMOS provides to you. But in this demo, I will walk you through the basics, how to set up the environment and how to call to the server side resolver. So as stated, we have TAMOS present in our environment. The next thing is to generate a configuration file that will be used by the tooling that we installed. And I will do so by calling TAMOS config. And as you can see, an editor was opened. And besides some configuration options that are stated like hosts of the remote server side resolver, information about requirements, formats, information about overlays and runtime environments. You can see information such as Python version or operating system name and operating system version. You can see also hardware information that was automatically detect and other options such as CUDNN version, MKL version, OpenBLAST version and also platform. So you see software that was detected in this case and also hardware that my machine has. These two are together called runtime environment. And it's one of the possibilities how you can run your application. So the resolution that I will show is dependent on software and hardware that you have. So that's why the configuration file states these options and these options are grouped into one configuration entry that is called runtime environment. You can specify multiple runtime environments and in that case, there will be created a directory structure that is specific for each runtime environment that you have. This directory structure is created based on overlays directory configuration option and everything that we will create here will be put into overlays directory. So that's the configuration file. So we can see we have hardware, software information but also what I will show you is recommendation type and that is information that groups intention of your application. So basically recommendation type states what's your intention with the application. The very first recommendation type will be latest and this recommendation type basically is resolution, very similar to resolution that Pippen or Poetry do. So the recommendation engine will try to come up with the latest software possible. So once we call Tamos config, we can check content of our working directory. In this case, we have also tot.yaml that's the configuration file used by tooling and sends to the server side resolver. Now let's add dependencies. So we will call Tamos at Flask. This is basically similar action as one would do a PIP install Flask but in this case we do Tamos at Flask and the tooling automatically creates directory structure and adds a Flask to direct dependencies of my application. As of now, we do not have resolved requirements for our application but we have just information about direct dependencies stated. As we've seen, we have that overlays directory. This is picked from the configuration file. So this corresponds to listing of runtime environments that are available. So here you can see we have overlays directory. In this overlays directory, we have Red Hat Enterprise Linux 8 runtime environment that corresponds to the runtime environment section in the tot.yaml. And here you can see a PIP file that was created based on addition Flask to our direct dependencies. So let's check content of the PIP file. You can see there are configured Python package indices. So in this case, we will be using pipi.org for installing dependencies. You can see Flask that is our direct dependency, no development dependencies, and then there are some additional configuration options that are consumed by the recommendation engine, but in this case, we will not use them. If you are interested in them, feel free to reach out to documentation. So we have everything ready to use the recommendation engine. The recommendation engine is called based on Thomas Advice command. What this command does, it basically parses the configuration file that we created and performs static source code analysis. So it checks what libraries users or I as a developer amusing and also what symbols from these libraries I'm using. And then the tooling submits a request to the server-side resolver that performs the resolution. The result of this server-side resolution is besides other things also application stack guidance. So here you can see information which packages were removed because of build time failures. So the background data aggregation of the server-side resolver analyzes packages. And if these background data aggregation spots that the given package cannot be installed into environment or causes some build time failures, it automatically removes the package from the application stack. You can see also other things present, feel free to reach out to documentation or try it on your own. The link that is present in the log will guide you to a page that has information related to the entry present in the guidance or in the report. And the final message says that there were no issues spotted when it comes to resolved or recommended software stack. Now, if we take a look at Overlays directory, Red Hat Enterprise Linux 8, we should be able to see also a log file that was created. And if we take a look at the content of this log file, we see packages pinned down to specific versions and also information about Python package index that should be used to install packages. Now, let's remove this log file and let's say we do not want to use latest software, but we rather would like to use software that is secure and can be shipped with application. Normally, if I do resolution with pip pipanth poetry, I don't know about the quality of software packages that are installed into my environment. And that's why TOT can guide you on the installed software. So besides these information, besides removing packages based on build time failures or installation issues or other aspects, TOT can guide you to install the correct software in your application. Okay, so let's open our configuration file again. And let's say that our runtime environment did not change, like software and hardware that is present on my machine did not change, but what changed is intention with the application. So I don't want to install latest possible software, but rather I would like to use some secure software as recommended by the recommendation engine. So I will go to the recommendation type section and here I change recommendation type from latest to security. I will write down my changes and now I can call to the recommendation engine once again by issuing TAMOS advice. In this case, again, the configuration file is parsed. The configuration is picked and here we can see lock that is printed. So besides analysis of build time errors of my dependencies and making sure that the application that I'm shipping builds correctly and all the dependencies install into the environment, I can see also information about, if we scroll down, about security vulnerabilities or CVEs. And here you can see that packages that have security vulnerabilities are automatically pushed away from the resolution. So the resolver tries to find another resolution path that satisfies requirements on my direct dependencies, but these dependencies that are installed into my environment are CVE-free or security vulnerability-free. So you can see that there were some JINJA2 packages removed because of security vulnerabilities. There were also CVEs in package-work-circ that the recommendation engine removed. And this is information from the resolution lock, but at the end we have recommended software stack reports and in this case, the software stack that was recommended by the server-side resolver has no issues and can be used. If you take a look into the overlays directory specific to rel8, round-time environment, again, I can see a lock file being present and all the packages pinned to specific versions and these functions do not have security vulnerabilities. Security vulnerabilities are scanned based on or the CVE information is obtained from the database that is available on PyPI, not on PyPI, but on the Python Packaging Association repo and it's the vulnerability database maintained there. So this vulnerability database is automatically picked by the background data aggregation logic and is prepared for the resolver so that the resolver can use information about security vulnerabilities during the resolution. Now let's remove lock file and let's say that we have constraints in our application stack. So I prepared one constraint and let's put it into our overlays directory. Let's check the content of constraints and here you can see we have one constraint on JINJA and this basically means that during the resolution we do not want to use JINJA that is newer that 2.11.2. These constraints files state information which dependencies or which libraries should be installed when it comes to, when, if they occur in the dependency graph. So unlike in case of PIP file which states direct dependencies, these constraints files state or instrument the resolver, how the resolution process should look like and some constraints on dependencies that are resolved if they are present in the dependency graph. Okay, so we put constraints into our overlays directory and now let's check our recommendation type. So in this case, we have recommendation type stated as security. Let's go to TAMLOS advice again. So besides all the configuration entries that are stated in the PIP file, in the TOTYAML configuration file, TAMLOS advice also picks information from constraints files and submits this information to the server side resolver. Here we can see again applications tech guidance and besides these packages that are filtered by build time errors, we should be able to see also information about constraints. So packages that were constrained are no longer considered during the resolution and if we scroll down, we see an error because resolver was not able to find a software stack or set of packages that would satisfy my direct dependencies as well as constraints on dependencies that I provided to the recommendation engine. So here you can see that the resolver can block potentially vulnerable or insecure software being shipped into your production environments and resolver automatically picks configuration automatically considers vulnerability database that is published on the Python Packaging Association repository. You can follow information as stated in the resolution log. If you would like to find more information about TOT, you can go to TOT Station Ninja that is our webpage and thank you for your attention.