 Mi je Autor Pibilt, in v prvnoj poživnih pristih nekaj ga bo, kako Pibilt je, in kako izgleda s dahljim, in v segundu ga izgledo, kako posleda. PIE build je vse obrženje, različenje systema. Jih so je neštačno, da je pitan pripomečenja na različno pitanje in tebrati, pa potreba vse vse neče počne, vse učne vse od učne, Files or EC directories or EC files. You don't have to remove them anymore. You don't have to add Debian options, Deven source options, patterns to remove these files. It configures your source. Even though this utils doesn't do much, in configure step, make sure that the same options are used in all steps. For example, this utils has this nice feature that if you pass some parameters to build step, it forgets about them in install step and tries to build extensions again. And by builds make sure that it doesn't happen. It simplifies building libraries for Python 2.3 or Python a lot. It makes it easier to invoke, for example, not only for this utils build system, but also different build systems like CMake or any custom one. It runs tests, which is something, for example, that the implementation from the developer doesn't, because Python has so many standards for running tests that the developer just simply ignores that and tries to detect the right testing suite, like no se, or if the interpreter is in the right version, then it tries to use unit tests discover thing, which was introduced in Python 2.7 and Python 3.2, if I'm not mistaken. It installs files to the right locations where other devian tools to later expect files, so you don't have to pass install layout depth or any other things that we used to have to do. Quick reminder about what DH sequencer actually does. So we probably in most Python packages already have something like this in devian rules files, which by default uses Python these utils build system, and the with statement is actually something that chooses the devian helper, because we don't have Python Central anymore, but we still have Python support, and this is what enables DH Python 2. And what DH sequencer actually does is it invokes these five commands, dev helper commands, which try to do the test to guess the right build system and invoke correct commands for given build system. For example, if it finds a make file, it will invoke make clean in DH auto clean, it will invoke configure command in the second one, and so on. But the problem with that is it works mostly with one Python version only, or in case, CMake, auto tools and other build system, the only one which actually knows to build for various Python versions and interpreters is these utils. So if there's a setup file and there's no make file, because make file has actually a higher priority, it will invoke the right commands for Python 2, and the problem with that is it doesn't support Python 3, and that's why I wrote PyBuild, and the support for Python 2 in this utils system is actually not as good as is very good, but it could be better. For example, DH auto test thing that I mentioned earlier. And what this with Python 2 thing does is it invokes DH Python 2 command, but the important thing is that it invokes it after all these commands. So PyBuild is something that implements another build system for DH sequencer, and DH Python 2 and other tools like DH Py support and DH Py Py, DH Python 3 are invoked after DH sequencer is already done. So that's the reason why PyBuild will never replace DH Python 2. It simply do different things. PyBuild doesn't generate maintainers, scripts, and so on. So please don't confuse DH Python 2 with PyBuild, because it's not the same thing. They are doing completely different things. And how to integrate PyBuild with DH sequencer. So you actually have to do two small things. First, dam is to actually set the build system because DH will try to use the default one, so you have to pass dash dash build system PyBuild option in order to tell it to use the PyBuild system. If you support Python 3, then you can add this one, but it's not related to PyBuild. The second thing is to create correct build dependencies. The mandatory one is DH Python, and please add it even though Python 3 package currently pulls that one in, because at some point I want to remove DH Python dependency from Python 3 package, so please remember to add DH Python to build dependencies, and it will also enable newer DH Python 2 helper, so you have to do it anyway, and please do. And the other part is actually not how PyBuild itself works, but how integration with DH sequencer works. Because PyBuild is actually a standalone command, and you can use it even outside DH or CDBS, and DH integration script, which was written in Perl, and I want to forget about it already, because it was a nightmare. This script tries to parse Debian control file and checks for build depends. If you add Python there, it will try to build libraries or scripts, because it's not only for libraries, you can package Python applications with PyBuild as well. If you add Python, it will try to invoke all these commands for Python interpreter, so the default one. If you add Python debug, it will do the same with debug interpreter. If you add Python all, it will check X Python version field in Debian control, and it will invoke all these commands for all requested Python version, the same for Python 3 and PyPy. There's one special option I want to mention here, which was suggested by Barry, which is name. This is a really nice option, because maybe a bit of reminder about how DevHelper works. If you have only one binary package, then DevHelper will install files to Debian slash package name directory, so you don't have to create any install files and so on. But if you add another binary package, so the second one, it will install by default to Debian tmp directory, and it's not Python specific, it's just how DevHelper works. And when you have two binary packages, you need to tell DevHelper which file belongs to which package, and that's what install files are for. And in case of Python, if you have only, for example, Python 2 and Python 3 package, install files are quite easy to write. You just have to enter there user-leap-python2-adopt-star, and it will install all Python 2 files from this directory to Python full package. The same for Python 3. You just have to put there user-leap-python3-star, and that's it. But if you happen to build a package for the back interpreter, it starts to be more complicated. You need to figure the right pattern for the back extensions and so on. It's already complicated when you have the back interpreter, and when you want additionally, for example, move this extension to different binary package, because, for example, the extension is optional and you want to provide any binary package and another one for extensions, then it's even more complicated. Maintaining this, you have to write this install files once, but it's a bit of pain to write them. So, another option is to tell PyBuild, what's the common name of your package. So, for example, if I have Python Maco, Python Free Maco, Python Free Maco X, then instead of full here, I have to put Maco, and PyBuild will know where to install it. For Python 2 it will use directory for Python 3, it will use this one and so on. And it makes really easy to add Python 3 binary packages for packages that already have only one. You don't have to care about install files at all. And that's pretty much it. If you want to, it's actually all the most packages for Python, usually look like. And we can go to hack lab and add some Python Free support if you want. If not, then I'm actually a big fan of customization. I customize everything. My VIM RC file is huge and so on. So that's why I made it possible in PyBuild to customize almost everything. And you can customize all these steps. You can provide different commands for each step or only for one of them. You can provide additional parameters to commands already generated for given build system. For example, if you don't want to do the work PyBuild already did for CMake or for these duties, and you want to pass one additional parameter, for example, you want to change the directory where scripts are installed. For example, you are packaging a game and instead of using user bin you want to install to user games or you want to package something for administrators and you want to use sbin. Then all you have to do is just pass install script user games, for example, and you don't have to care about all other parameters so that the thing that the hack I added to force these duties to remember all the options it will still work. You just have to pass additional parameters and don't care about anything other. You can also tell PyBuild to invoke different commands before each iteration of this build step or any other actually. If PyBuild invokes a command to build for Python 2.4, 2.5, 2.6 and you can invoke another command before each of these commands and after each of these commands so that in the examples later I will show you how useful that can be. Actually I saw a lot of packages which were overriding in Debian rules overriding these steps and adding four loops which were adding these new commands or passing new commands and new parameters and this is much, much easier with PyBuild. And almost any action can be disabled I will show you later. You can actually even create your own build system on the fly just by defining few options. You can tell PyBuild to support completely different build system which is currently not supported by default by PyBuild. And how can you customize it? There are two options. You can pass a command line option or you can environment by variables. All of them start with PyBuild underscore. Here's how you do it. You can, the first one is one I like most because it has some additional features like you can for example add underscore and interpreter name or interpreter version and it will work only for this interpreter or this version. And if you choose to use the command line you will have to invoke PyBuild twice. And the second way of overriding it is in devian rules is to pass after the dash-dash. Is it PyBuild 3 or can you tune from Python 2? It's all PyBuild. Zigo, ask if it's PyBuild 2 or PyBuild 3. No, it's PyBuild underscore option underscore Python 2 for example or Python 2.4. There will be examples later so so you can pass these options to DH Auto, Instal, Build, Configure or whatever and if you use this it works like any standard tuning tool so the two dashes means I don't care about these options and pass them to the next tool and it will pass it to PyBuild. Another one is to set environment variable inside in the line where you overwrite the DH Auto full. This way if you export in the top of devian rules file it will work for all steps and if you do it like this it will set this variable only for DH Auto Instal in this case and as I mentioned earlier you can also involve PyBuild directly but if you use the last one you lose the integration with that helper so it will not know which interpreters are selected which options you want and so on so you have to pass it using command line parameters this way if you don't like DH for example or need to invoke some really weird stuff then that's probably a way to do it actually DH integration is doing that but it feeds PyBuild with some parameters parts from devian control file for example but you can do it by hand as well if you want and examples I already mentioned install scripts and that's how you can pass it just one note about that please remember that you don't have to quote it here in make file because I already saw some people are adding quotes and you don't have to do that you actually shouldn't do that in make file and another example if you want to for example pass test directory to no se PyBuild by default in build step creates a new directory where the built files are where they stored and changes current directory to that when you invoke tests the source directory is not taken into account because I actually it happened to me more than once that I built something and invoked test and they failed and after I realized that I'm actually using the wrong directory because Python is by default using current directory it's on the first place in syspad and it's a common mistake I did that many times that's why in the test stage I changed the current directory to the build directory if your upstream maintainer doesn't install tests with library then you have to tell no se or py test where to look for these tests and this is how you can do it in py build just use test arcs so this parameters will be this option added to the nos command and you can actually use variables in in arcs in these options there are quite few of them like version, builddir, installdir interpreter version can you can use version.major for example if you don't want the whole thing it's all described in the main page you can use it to customize your commands you can also that's what you were asking about if you want to provide an option an option only for one interpreter you can do something like this so underscore interpreter version or only the main interpreter or version interpreter testdir is actually an option where you can define a different destination directory for extensions only so if you want to shape extensions in different binary package all you have to do is define this variable and pi build will do the right thing you don't have to overwrite dh auto install and move files one by hand or create very complicated install files and so on pi build does it for you another example is 2.2.3 there are many ways to do that so really big scripts in devian rules that tries to invoke 2.2.3 in a way that it doesn't conflict with python 2 because once if upstream ships for example tests only in the main directory but you invoke tests the same directory is used they will fail and 2.2.3 is needed because it's possible that the same script can work in python 2 and python 3 but if 2.2.3 is needed and upstream users doesn't install it tests with library and you can only use from directory from the root directory of this package then you need to deal with 2.2.3 and you have to do it before invoking tests for python 3 and reverse it afterwards because otherwise the tests for python 2 and with this simple free rules python build will do that for you so it will, the first line will copy tests from root directory to build directory and for all interpreters and the second line will override the line, the first line only for python 3 packages so python 3, 3, 3, 4 and so on it will do exactly the same thing but it will also invoke 2.2.3 in tests and afterwards in python after tests for all interpreters it will remove this directory when they are no longer needed it will just remove it so that's one of the examples where before and after options are useful you can think that moves extensions to different package is actually customisable as well so you can tell it you can define extension by providing a pattern and instead of by default python tries to find SO files with the abi thing and all other weird things that end in python file name but you can override it and tell it that you think that extension is something with PNG file so all images will be moved to this new directory another example how you can disable things in PyBuild because you can for example need python or python all in Debian control files built depends you don't want to build it for this interpreter for example you have a script that uses python 2 but you build only python 3 packages so you have to add python to build dependencies but you don't want pyBuild to build for this interpreter and the first line disables python 2 completely the second one disables tests step for python 3.3 for example if you want to invoke tests for python 3 but one version doesn't have support in some other dependency because it was not rebuilt yet or for some other reason you don't want the tests for this version fail and you want to disable it and just for this version you don't want to disable the whole thing for python 3 but just for this version because this one doesn't work and the second line does exactly that and you can actually disable many things at once so if you want to disable configure step for python 3 that's the first part here if you want to disable everything for python for version 2.4 doesn't matter which interpreter it maybe python 3 python 2 in the back and so on if you do that python 2 it will disable python 2 but not python 2 in the back so if you invoke python 2 in the back then you have to remember that you have to disable the back interpreter as well and an example of new build plug in new build system if you set system to custom and define parameters I will not get into details because we have few minutes left then you can ignore the build plug-in plug-ins that are defined in pilot and do something completely new you can define your own build plug-in and that's actually what build plug-ins do if you have something like this and want to share with others and I will replace it with proper plug-in which will detect if there are some files specific to given build plug-in it will use these commands instead of what it does for other build systems and before we go into questions I just wanted to say that I don't need any help with this I don't want you to write any plug-ins I will do it all myself I will just report wish list bugs and I will do it for you and I really hope that this reverse psychology thing works so questions I was just sitting here messing around with it on one of my python packages that I have maintained already the one thing that the upstream that I do is they use ePy doc and so I have to override for that would that be a situation where you could use the plug-ins and just override the testing routines that would be done to generate the docs PyBuild doesn't deal with docs actually but you can override DH auto build tell it to actually invoke the DH auto build so that PyBuild does the right thing and then add one additional line which invokes the command that generates docs, I actually do that in many packages two points first is I've just only recently looked at PyBuild in very briefly but the environment variable thing it seems to be you're using a lot of environment variables so I mean in a different context if I saw shell script with that many environment variables I would be inclined to say hey let's rewrite this in Python and stop using environment variables because obviously you've got actually you don't have to use them almost all of them can be passed as command line parameters I just think it's easier in DeGon rules general impressions here but I mean with environment variables if you misspell an environment variable most likely what's going to happen is the program is simply ignores the variable because you misspelled it so in other contexts where you have a grammar you can parse that file so here's an unexpected token or whatever but it's not valid here so it seems there may be some QA issues related to that design choice second point I want to bring up is well I don't do a lot of Python module packaging I'm a Python programmer I don't do a lot of packaging but I've been doing it for a while and it might go two or three years in between actually touching a Python package and it's happened several times to me that I will look at now you'd update this Python module, a package or whatever and there's a new way to package Python modules for DeVig so I'll go and read about this and I'll be on hopefully we have only one and it will rule the whole this is where I'm heading towards the other ones are either out of the archive or deprecated you'll go and look into it and there's two ways to do it so which one is the preferred one you do some more reading some people prefer one I would suggest to go to this page and Barry prepared a really nice guide how to use this stuff and it's very opinionated but it describes what we think is the best solution so it doesn't describe all the possible solutions but it describes something that we think is the right way if you follow this website then you are probably fine and by the way since this morning that's what SCDAP generates I uploaded a new version with some patches which are using PyBuild already I don't find opinionated problems when there's multiple opinionated positions in general how do you suggest we solve the issue where different people have different opinions I don't necessarily want to take an opinion on everything but if there's something where I'm not an expert and I would prefer to follow best practices we go back to windows why I said best practices not common practices we have really not so much time just a quick question maybe if not then thank you