 So, welcome you all to the Python prof, my name is Andy Bart, I'm one of your risk managers and what I intended to do with the prof was just to discuss about pricing. And I think it would be a good idea to take the chance of today to at least get an understanding of how we continue and the best to be able to actually go this way. So, discussions about how pricing models are structured. They are some issues with the current structure, at least for me as a risk manager. So, I think that is for me the co-op part of it. If there might be other issues too, but I wish that the viral types say, the ones that are now really hard for us to come first, the others should come later. So, this is up to you. And what makes me quite happy is that the local is here as the pricing manager. Also, I'm a Python user, but I'm not a very Python expert, so if I say something silly, please forgive me. So, I think this discussion is to get a better understanding and a more common understanding. And I would say, I think my role is this discussion mainly to meet this discussion so that we can actually get to the salt. And what I propose now is to start there on my point, that there is a bond between senses about what expectations are and perhaps if he sees the problems that we need to resolve. But please don't make it to a longer talk now. We can just do it directly after the introduction round. And please also say your name. So, I would say, because that's the start of my left, Matthias. So, who are you? My name is Matthias, close it. I'm currently maintaining Python. And well, I think we have something to do with the current situation and to make a proposal after everybody didn't mistake what we expect from the Python in the end. So, it's okay. Yeah, my name is Wolf-Munow. I am a Python user at home. I'm just passing the word, so. Okay. I'll just say a few words for you all, but just take them to the salam. I'll just say your name if you don't expect anything. I'll just want to visit you all. I'm Margarita Mandrolla. I program in Python, and I tend to maintain Python packages, so. Barry Hawkins, new maintainer in the queue with Andy as my application manager, actually. And I have an interest in our direction for Python strategically and also entertains Python actors. I'm Lars Fritzenius. I maintain my packages in Python, and I would also like to make sure that you watch them. Never ever find, compile Python files. Thank you for all the work. And I'm just interested to see what's the basis of that. That's why I'm here. My name is Wolf-Cohacico, and I intend to package some Python software or some programs on it. I'm Mohenia. I'm using my Python memory as work, and I completed my first Python application a few days ago. I'm Rafael Elsog, and we simply started the Python model team to maintain a collaboratively more models and more interest in the policy issue to get it going for the future for the migration. I'm Flipper, and I'm a frequent Python user, and I would like to help to package Python models and see the situation improving. Hi, I'm Stefano Zactiorelli. I'm a Python user, and I'm especially interested in knowing how we can use Python as a core language in our distribution, since it's a frequent need to develop accessory tools for other packages, which I found quite convenient to develop in Python, but it depends on the problems, and this is something I want to know more about. I'm Lukma Wolflach, and I'm interested in seeing about Python policy and some kind of migration set up on how they're going to work and help thinking about it. Hi, guys and females. I probably with Python quite a lot, and especially in English, I have a question on this. How do we handle Python eggs in the big problem way? My name is Patricio Baez, and I use Python and also program a little bit, and I have to make a collection of Mexican federal laws with Python scripts, and I would like to learn how to package those scripts in the big package. Just one remark now, I mean, most of you probably noticed that my English isn't too good, I know that. So what I like to do is to speak a bit louder because it makes it harder for me to drop consonants. And I think the same is valid for some other people to zoom also, and for native speakers, they speak good, but we non-native speakers have issues to understand it if you drop more consonants, even if it's not dead for the native speakers. So please all speak a bit louder, because I think it makes it a bit easier for us all. And those, this is a remark that lies to me as well. So now, I think Mathias has prepared a bit about the translation. So, anyone else who wants to give an actual talk? So it's just Mathias. Okay. So, we'll be right here. Okay, including you didn't say how you are. So I said you can do it. It's just to say it's too loud. Okay, so I'm just not wet, and also a material of pattern support is used by a few pattern modules now, which try to render the default for pattern and being used depending on the patches coming up. And also the original DH pattern is currently used by most patterns. Okay. Okay, so just wait another few seconds till everything is there. Okay. Now, what is the government state of Python packaging in Australia? Hopefully, we can support more than one version of one Python version in Australia. For our last release, we even did support about three different versions, which is now used to two versions, 2.3 and 2.4. We did support some other Python implementation as well, like Jison, that's a Java implementation of Python. And it's not enough to just support some core packages, but we need to, if you want to support more than one Python version, we have to support modules and extensions going up in Python as well. Unfortunately, we do not do that for all module sets. It's somewhat inconsistent, so we have to support for all modules for default Python versions, but not for other Python versions installed on the system. Currently, version changes require some effort. Usually, we have to touch every package, which depends on Python, if we want to switch from one version to the other. For example, 2.3 now to 2.4. That's a bit unfortunate. Plus, the migration to testing is very painful because in the progress of making the version switch in Python, we have to touch every extension module, that means we rebuild all extension modules against new versions of the Shopify version on the system, which are not necessarily in testing and have to migrate all of that packages in a big frame to testing. That's, well, a major pain for some of these managers, and I think the same why Andreas is here. I'm also here because I'm exhausted, but I'm also a priority member. Okay. So, besides the pain of the police team, well, the current system works. I don't see any problems with the current state of function. People arrived in the meantime. I've seen, perhaps, if all of them want to say who they are. I've seen a scene. Okay. Oh, okay. You? There's each other. Hi, I'm Michael. Yeah. Michael? Yeah, I said Michael, but most people say Michael for a second. You can call me either. I will. Okay. Which other requirements for packaging in Debian? By itself, we don't need different Python versions in Debian. It's nice for developers doing development in Python to be able to test the packages with different Python versions, but it's not the goal to have different versions in Debian. But unfortunately, there are many applications which do not run with the latest Python version. The most prominent example is the application server, which, well, the current version 2.9 actually runs or uses Python 2.4, but unfortunately, the most popular application for the server, cloned, still requires Python 2.3. So there is a need of having different Python versions in the distribution. It would be nice to have a uniform approach for packaging. Usually, packages should not have to choose some kind of packaging help depending on, well, having an extension model or in Python application. So it would be nice to have some common support for packaging. Yeah, one requirement is to reduce the amount of work for Python version changes. Ideally, it should be able to upload just one package, namely, Python defaults, which chooses or changes the link from Python 2.3 to Python 2.4. That would be the most ideal route. So first, it would be nice to have something to see what we actually need to change. Currently, if we look at the archive, we can hardly see which kind of packages need to change for a Python version change. We can track the dependencies on Python that have to look at the packages themselves to see what has to change, what we have to do to do the version change. The second thing is to reduce the package rebuilds so we don't suck in new dependencies which may hinder the migration to the testing distribution. And it would be nice, even if we do a version change, that we do not have to recompile all the binary extension models as well. Yeah, and last but not least, easy migration process. Well, we can't help these managers doing that, but it would be nice to have that migration process fixed. Yeah, so two different issues, I think. Okay, just a little round. But how does it need to be fixed? Currently, we've currently required us to set all packages together and now we should go to ECX, which is a normal library switch, if you change from libfoo version 1 to libfoo version 2. So usually the packages are all packaged as they will first, and then go in together, which can be quite hard, because if some packages are see-bunky, or they pattern another library, in the meantime, it could be a large transition. And what we're doing for libraries, what we're trying to do for libraries, is that we keep the library in testing as long as any package is in the library, any packages can go in one by one by itself. And something similar could be done for Python also, but yeah, I think the order in which we work on it is first to say, okay, how does it work like for the Python point of view? For example, I think that something like have a uniform approach for packaging is quite an important topic, independent of anything about the lease management or not. So if you say you have something, a solution that fulfills all of that and tweak it to the lease management side, then I would say go for it. But I want to have first of this topic how it looks good in Python, and later make the tweak in other way. Yes. Right. And the ideal thing would be if we have at least very few or not any version information at all in the source package. So I do not have to change something if we introduce a new Python version, for example, 2.5, or if we rebuild the package to include the plot for a new Python version. So that's a proposal. Well, it was published maybe a bit discussed on the Python. We should talk about some supported Python versions. Currently we do just know or we do a hard code that a module is built for used to be built for Python version 2.3 and 2.4. But that's already hard-coded information in the source package. So what it can do, we can have some meta packages or dependency packages named Python all and Python all slash def, which depend on all so-called supported Python versions. Means the package source is able to extract that information without relying exactly on the supported Python versions. This alone would allow us to just recompile the package if we drop a Python version or if we add a Python version. The second thing would be to add information to the control file to have an extra field Python version for the source package and for our binary packages. The rationale for doing that is to just look at the packages and source files to be able to say, for a Python transition I need to change these packages exactly these. Currently I have to look at the content of the package and find out myself what I need to do with the packages if I change the Python version or if I add a new Python version. So how would it look like? In the source package I have an admin Python version. The value can be or any or some combination of well, a relation and a version or an enumeration of some versions. That version information is just copied to the binary packages except for the any value which is replaced by an enumeration of versions which are supported by this package. For example, if I have an extension module I need to build it for every Python version I want to support. So I have to rebuild that package if I want to add support for another Python version. So that package is only usable for some kind of well, Python versions but I do not have to change anything if I rebuild the package. So for example, these managers can do that change with a binary NMU without any interaction by package maintainer. Right. So how do we solve the other things? That's an approach which was well already implemented I think two years ago by Python Central by Bustian Klein-Ellen. Packages which install their modules outside of the Python class or we call them private or packages with private and shared modules. So what needs to be done with these modules? Currently we do byte compilation of these modules on installation and byte code removal on package. At the moment we do not if the Python version changes we would need to have to recompile the Python byte code. The packages do run without that complication but they are maybe a performance hit if the byte code is compiled on the fly for every invocation. So we need if to recompile the byte code if the Python version changes for this kind of packages. So we have when the packages install inside it will use our live Python so called modules and extensions. We do need an approach for the packaging which handles modules and extensions equally or else we have to mess with our dependency system because we can install packages for which the pending packages are not installed. The idea is to collect all Python x.y full packages into one Python-full package. That means we reduce some kind of duplication of the files which are currently in the versioned packages but we add some duplication for some kind of packages namely the packages which contain extension modules. The idea is to install the binary independent files into some location outside of the Python pass in the USR share some location package name and some linking these files into USLI pricing on package installation and do that for every Python version which we have on the system. We do install the extension modules directly into the package for every Python version we come to support on the system. That would mean currently we have an extension compiled one time for Python 2.3 and for Python 2.4. The benefit is that if we once have this package we do not have to touch it anymore if we change the default Python version from 2.3 to 2.4. So it eases the immigration process and we don't do anything with that package for the transition anymore. Quite. There are currently oh, that's not on the slide anyway there are currently two implementations for to support some aspects of this system or this package. One is the Python support written by Joss Wett which currently is unstable and supports private and shared modules and architecture independent models. The second implementation was developed by me based on existing Python Central from Bastian. It's currently available on people.dpn.org an outdated version. The implementation is completed and needs to help us support currently there's not much done and of course needs some testing. I did intend to add a URL type it in the browser. I know it's a browser. Just for a little bit, I'll wipe it down with tears. Yes? Hi. Oh, what do you have in network issues? So if you want to have a look at the current state, that's a we have currently network issues the switch is done probably continue without the URL before you guys have outfitted. Okay. So just wipe down the URL of the data. Hope I keep that IP at least for today and put it there on a more well, common location. Right. So that was my brain now. Thank you very much, Matthias for that brain now. Just take the test it out. So I think I should call you now because I know so anyone else who wants to give a short start is very awesome. But if you just come here and stand up it might be better for you to make it easier for us from the stand to stand because it's getting better. I can give a few words on the package with this pattern currently we have three kinds of packaging. First you have a binary switch switch with a pattern name with a pattern or pattern 3 package like this one with this package we put the currency on the current pattern version and this works. So then there are primary binary extensions the current pattern policy there are two sorts of packaging and this is one of the problems Matthias described because it's not consistent. Option D means Python 2 requires Python 0.3 option B is only a Python full of package. So with option B when there is new Python version the package is rebuilt and then there is only one binary module which is provided for the new Python version. So could you explain the private models thing what you mean by that? These are modules outside of application which is developed. Yes. At least Python So currently most packages use DH Python which has to support all these cases. This is why this is a horrible piece of code and it's kind of sometimes broken in current cases. So for private modules they are byte compliant and installation and removed in the pre-arranged script and this means the package has to depend on what I call the strong Python dependency currently we require that the package depend on Python at least 2.3 and at most 2.4 which means also these packages have to be rebuilt when new Python version is introduced. So for binary extensions anyway DH Python will change this dependency when the different Python changes to Python to Python 2.4 to same as option 2. Automatically you mean the maintainer changes the script or you mean it will just change the compilation automatically. Yes, automatically. So you must make a binary on the upload then you will change it. No, because about binary view is not enough because Python food is a large cater hall and also Python 2.4 food has to exist really but generally maintainers create maintenance that supports option 3.8 create the byte in 2.x version when it is introduced. Yeah? Generally for the dependency problem what would be a problem is the dependency relation is set correctly but the big problem against a binary while you cannot do binary any uses we have to introduce a new package in the control part that's important. Yes, that's the case when the maintainer of package is introduced the new version between the time the new Python version is introduced and the time will become default. Generally, Python 2.4 has been there for almost a year so we have only many packages which provide this Python 2.4 but yes, you are right, if they don't it has to be done and it's also a problem. Option B, of course is much simpler because it will remove the module to the new character structure of the new Python version but of course the drawback is that you only support one version at a time. But for Python only extensions currently in the Python 2.3 and they are treated mostly like private modules which means they are by combined and post-installation and removed and removed and it requires the same penalty. So for all of these I guess the HP term was written that Python transition meaning moving default Python version will require for most packages only the rebuild. So it was the goal, it is not perfect for this because it is fragile, it is a fragile system. So the introduction of Python support tries to deal with 2 and 4 only with Python only extensions or private modules. For private modules as they are in the specific the only thing you need to know is the Python version they support and the directory can be found. So what does Python support is the package register in Python support that lays by adding a file in a specific directory. When the different Python version changes Python support rebuilds all of these Python PYC bytes. So you can drop this dependency and you can pass the Python transition without spaying. You can float it forward Python support also needs to know which Python versions are supported and for Python versions it will build a specific directory for each Python version Python version there is a directory like this Python version by module it will build the PYC bytes in the directory. So when a new package when a Python version changes there is a thing to do because the new modules are already here. That's the Python only extensions can be as a dependency change change when you have a dependency change where I have Python and Python all but one tool is only scripts and then it sends a pain from something to an S.O.S. platform how does it pay for it how does it work but first of all I have to make an definitive comment now about that if you look at your watch and Drollima is actually beginning to offer his time to move his time off another time if it said it would be okay for you you could continue another time slot here it's a good conflict with the kernel talk but that's it so I think it would be good to continue now because there has to be a start and a finish of our discussion would it be okay for you? I can continue with you you should write starts also start with the discussions I think we should start to describe not to tell you a bit you were interested in the point of difference in chain I discussed it on IOC with Stephen Essex like this here and we suggested a new Python provides a decision file that could help with this so that means all of this should probably be put in the Fyton without too many problems now most of the code for the Fyton support is written it only means about the version support any versions I think so I think what you said is correct I can see you can say is there still one problem with Python support when you have one package which provides support for all Python versions and it's actually which depends on a Python extension model then you screwed because you can't depend only on the Python only model because you're not sure that you're going to have the right version of the Python the extension model behind there's two solutions either we decide in policy that we only support for the current version or we need to say to the user of the first module that he has to take care himself of depending on the right version of the extension model I personally don't think that's an option to say to the user if you can't I don't think I don't view the user really I mean the maintenance with the Fyton model that's like this everyone will understand what he means so we have the extension let's say a C extension and it's used by Python in what Python 2 C so if we are if Python thing depends on Python application depends on this one that's the case you're describing the application is using the default Python version to the world but if it's using a specific Python version it will not work but basically if an application needs Python this one is in all packages and this one is in any package Python anyway so the application now depends on let's say it depends on Python 2.3 Python this one here because it's a typed again it's this module and this is what it will internally cause but it doesn't care about why should it be and then if this version has default version before it's correct I don't have any idea just my own opinion on it in this case actually it should not depend on Python 2.3 but on Python 2.3 something like this one if it was a built it wouldn't change it if this device has Python 2.3 something how and it will use a switched default version then this will only call it this one this is for application using a specific Python version so it's not affected anyway by the default but it would be inappropriate for a package which uses a specific Python version it would be inappropriate for a package which requires a specific Python version for use to depend on a package named Python-foo because Python-foo is the namespace for the current default version and that version will change over time if you want to declare that you're using Python 2.3 that your dependency should all be Python 2.3-foo otherwise you're mixing and matching between the current default version and the version you actually need and your dependencies there's no promise that a later version of Python-foo will satisfy their dependency the problem is not as long as I depend on extension models which are packaged in old ways they always have the problem of having well-worked dependencies because I cannot say if I depend on one Python 2.3 package in the chain I cannot say depend on another Python 2.3 in the chain as well but the dependency could be fulfilled by a Python 2.4 package you're saying if you depend on a package that's Python 2.3-foo that Python 2.3-foo would be implemented by a package that depends on Python 2.4-foo that's a broken Python 2.3-foo package because it cannot provide the interface Python 2.3-foo Python 2.3-foo that satisfies its own dependencies I don't think it's broken you can't provide it if you don't actually provide the interface perhaps I think we missed part of the argumentation which was called yesterday so actually the question is if you have a package that only contains goods it basically is version agnostic so you have some possibilities as you provide all the packages for all versions then you could have a clear dependency chain like with another or you say okay I have only one package which just has the provides header but then it cannot really depend on what is there so actually you must make sure manually that you have everything only scripts or you have this point if you declare a provides for any version of Python you can't you have to depend on what it's part to actually implement that but we have now but in that case I don't want to talk over it now we're supposed to be for that if you are I think it's clear it's what you describe some currency problem but it means in this case making this package it means Python is 2.3 so it's better than Python 2.3 so it means what we want in the end we will bring through this package all Python versions through the binary expressions right I think it's quite I think it might be good if Matthias if you could just look on here the board Matthias because Python mega widgets it's a package it's binary all and it depends on well on tk so if you do package Python pmb with Python support on which packages it depends on either Python 2.3, tk or Python 2.4, tk so I cannot say well if I start with mega widgets with Python 2.3 and I do not have Python 2.3 installed it's broken but a package that's built that way must not provide Python 2.3 that's tk I would remember that one we don't have a package for Python 2.3 we have Python 2.3, tk and Python 2.4, tk right and currently finally all depending on any package containing an extension model which is the version which is broke and that's about 2.3 of the so right what I did say just have just don't have version packages for extension models put the extensions for all supported Python versions in one unversioned package that's somewhat an overhead but we have the possibility to keep our strong dependency system and it eases well to pick up anything we do not have to touch these packages again if we do a transition 2.3 and 2.4 we do the transition we do not have to touch these packages anymore I agree with what you're saying concerning putting all of the extensions from the different versions of Python within a single package if you have a program that needs a specific version of Python what does it depend on the Python set for if you're calling user bin Python 2.3 as your interpreter and you need specific models you can't just depend on saying okay I require Python-foo because if you say that Python-foo doesn't guarantee Python 2.3 because we're making it so easy to rebuild this it's not sooner or later I've been in a view of Python-foo that completely drops 2.3 support and it's going to break the dependency of the existing package so they need to still be depending on if it uses user bin Python 2.3 and it uses the module it needs to depend on Python 2.3-module and so something has to provide that I don't care if it's a real package if it's a virtual package whatever but we need to not confuse Python-foo and the Python 2.3-foo because they are both useful in different circumstances it's fine for module maintainers to say I don't care about providing that interface for people that are using a non-standard Python version that's something that they get to argue with the people that want it but if they're going to do it and people that are writing applications that are doing that using a specific interpreter need to have those available or they can't package properly if you have that package with the old version you cannot provide the same way as what you just said Mattias suggests putting all binary modules in a single package solves the problem for these binary modules just like happens that solves the problem from Python introduced so they are the same approach for two different types of agents both together we have a consistent system okay, so I now understand my understanding of what was said is now that we have some approach that Mattias proposed that solves this part of the problem so other issues with Mattias approach or any issues that you want to discuss we should just discuss about what are the issues so this is someone who wants to say something as Mattias proposes what you're lucky basically is an example of working package that we can reuse to have several binary extensions it's the same extension for several versions of the same package there's a URL I want to do at the end of the slide that works again by the way the only problem you see in the package is that I don't use DHPython at all at the moment I just do the same as Mando which should be done by DHPython there's one example for binary for all module and one example for module with extensions or a package with extensions and well two interpreter versions are 25 as well just call it okay in any case I have one question you did mention a specific keyword of any that would say all the versions and do the magic for everything do you think it's useful to also have a keyword of current for somebody who only wants to support the current version why not why not use all that current save space in the archive for stuff nobody's going to use it doesn't cost anything other you have only one package so why is that the same the package is bigger because you're providing free binary versions no no no for a binary extension it's larger if you provide it for different versions for packages with extension models we could have something like don't attribute which is translated into the python version 2.3 or 2.4 in the binary package well that may be needed for some very big extension models or for extension models where it's difficult from the build system to actually build all these different extension models but we should try to have at least all these extension models which are very low depending on the shape build for all these supported bytes I agree you have a different keyword and if you see that it's abuse you can still make a harder policy to say okay this word you must not use the curve because it breaks it or that you can still use it so you have to introduce the keyword and see how it is used in real life it might be useful in some cases to introduce it first okay, anything else? yes sorry, you're behind me I have concerns about Matthias' proposal about the new beta data and I'm not sure it's really needed all of this can be done with arguments given to DH Python that's what I intend to implement for the DH Python with Python support it would just be minus n for more version or minus n for the maximum version and for more complete versions that would be also possibility and you don't need metadata in the GSC and the control finds I don't see what it brings now I may want to say something in your discussion it's part of the discussion if you have a really good argument to have data in your console files I can ask you we need to make a GSC for Python more specialized GSC for Python and I want to automatically check anything that's in the console file can be extracted by scripts you can even say in some cases okay, this might be an interesting problem to use or whatever if it's in the data rules somehow hard coded identity to what comes out at the first solution is a console file because a lot of pictures are high so now back to the discussions I agree with that definitely it's useful because it separates your data from your code and gives you the ability to script it it makes it easier for even a human to be able to look in one place as opposed to digging through a rules file and see how the DH Python may be invoked in various ways I think the best solution is that DH Python can read the information from the control file and also take those arguments so that if there's a reason to override the control file you can do that the problem becomes then a problem of complexity because as I said, DH Python is a really horrible piece of software and having to pass the control file to generate other things beyond that will become even more complicated and that's a concern that's also code that still has to be written because version support for Python support it's really a building in the Python support for the DH Python it would have to be written as well to really one of the largest okay when you are okay, Matthias when do we want to sit down and do this after the next talk I can see H8 so any example that's on the paper and assuming that any is currently 2.3 and 2.4 what are the dependencies of those three packages the three packages on the board that are written up there an application that uses either a Python or a Python 2.4 a Python or a module that depends on a Python or any module a Python or any module when 2.3 and 2.4 are the current ones in the archive what are the provides and dependencies for each of those packages Matthias, as it is your super close you want to provide the other same I can't do my work with any so how do you ensure that when 2.5 comes out and the Python or the Python 2.5 the binary package updates well I do not have any kind of information it's not a problem for binding at all it's a problem for the binary well you can identify that you see when we need to identify the Python 7.8 right so I don't see a problem to well get the Python provides a Python version for the module what exactly is that going to be I can see a couple of voices sorry I can't see the exact problem you tried to describe alright if we have if this one depends on the default Python this one's all so it'll just work no matter what and this one was built with 2.3 2.4 support now when Python 2.5 has come out we've implemented your proposal and we're ready to transition to Python 2.5 so Python 2.5 gets uploaded this one starts playing in Python 2.5 this one keeps working without any resource changes but this one needs a new upload and there needs to be dependency somewhere here to indicate that the new version is actually going to be loaded now the dependency actually will be Pythoning the other one this one this one 2.3 no, no, no this one this one and this means Python Python Python this is what controls that you cannot update to Python 2.5 until this one is deleted that's of course correct that's currently the ground approach okay now because you have here now some things to do that is to delete into a 4 but it's not possible currently so it's followed in the next because in one version the secretary has freedom procedure okay now instead we have this script hard credit to use Python 2.3 because it has a keyword that can introduce Python 2.4 it doesn't work and that depends on this which is an old package so if you want to use Python 2.4 then how do we actually ensure that the right stuff is installed or which Steve mentioned yes that's what I believe we need to be using this and that means that any package which provides Python 2.3 as module if it requires other modules to use in order to be using in order to be declaring that provides it needs to depend on the Python 2.3 versions of all of the module it uses as well so this one is going to have to depend on Python 2.3 and no the application needs to depend on this okay from Python 2.3 it's provided it's provided it's provided this is the version that was my understanding of what you discussed is that correct? if you have basically an application which uses just come out and write it down it can use which is a non-default Python 2.3 so rather than just depending on this and having it very transiently we need to explicitly depend on all the way down to Python 2.3 no how do you think of this here's what I'm arguing should be the case I'm going to put the application actually Steve I'll come back to anything I don't just name it Python 2.3 that's the first one that's the easy option so this mention needs to depend on what's actually going on I'm sorry I have to show you by what you're doing this one is close by this dependency so we can go to Steve just one second just one second I'm still right is that legible at all anybody? no application here it's using user bin Python 2.3 as its interpreter that means it has to depend on the Python 2.3 version of whichever module it uses this may be a virtual package and in this case we're saying that it is a Python-py thing provides Python 2.3-py thing and that's what satisfies this dependency but in order to declare this provides it has to depend on not only Python-pybin which is the module that implements the architecture any module that implements the extension it depends on it also because of this provides has to declare this dependency on Python 2.3-pybin as well so that people that are depending on this virtual package actually have a usable implementation on it that's my argument does that make sense to everybody? does that? it works obvious I think there is some disadvantage of that approach there are some disadvantages it makes the dependency to be more complicated I don't know if it's going to kill us when we do all this I don't think it's more complicated but for the users it just needs a 2.4 version it still gets installed with the 2.3 version which means that it installs Python 2.3 so if there is anything where you have any version dependency in your footchain you will get all Python versions installed unless we have one more test all Python extensions for all Python versions single package because this provides you can have more as soon as you have something who you are you could do it you are right that in a sense that is a disadvantage if you do have a package which actually depends on it it's not as virtual packages it's actually implemented as separate packages that is a disadvantage because you have them all installed you deal with that by saying I'm not going to support the other versions I'm going to support the current version which is why I was asking for that it's not it's a footchain it doesn't fit in mine I think we could do it does anybody have a counter proposal I can't see what you're making what you remark is that in that case you also have to update the Python pricing package when you migrate to Python 2.5 because you need to add the new provides as in the new dependency to Python 2.4 you don't need to because if you just have to do it virtually you could do it automatically by DH pricing if you don't need to just use a bit of an emu it's an architectural package again because I think you just need to build it so when will we be able to make the emu for our old package never because it's one foot I'm sorry but we can't do it because we've just implemented a different source version of dependencies on actual stuff to work right and if we start bumping the actual version of the possibly one then that will break you're right but what you could do is quite easy and get emu to just download the entire upload you just file these and then touch the console file I've got a question for Steve I'm very naive about what if we had this idea of the binary package that depended instead of including 2,3,2,4,2,5 binaries that actually depended on those such that if you had a very sophisticated administrator they could provide you to create virtual packages to satisfy the provides for 2,3,2,4 when they wanted to go to 2,5 and have a minimal system the state of the art today in Python packaging is that each version of the package region is a separate package that's kind of what we want to get away from because you can't get any of that because it creates no entries in the full file so if I can also answer that I think that would be possible so if you take the Python 2.5 version of the module install it locally and then just have a tilt after it's got the appropriate dependency satisfied already and you can do that with a bit so that should be possible if you're doing this local system which is not allowed in our distribution in any case yeah I think that's fair because especially what you have on this system maybe you have carried a lot of this not only about one okay, so anything else? the question I was asking earlier does anybody have a counter proposal that will satisfy the requirements of an application using a specific version of Python as its interpreter we get the dependencies one but we have one application that we have we need we cannot install a Python version which is not the default we always have to install the default Python version so we'll talk about that in a second just probably for a second yeah that's a good question okay I didn't this is Python Essentials both so I've got another naive question yes I have some Python that I've written that requires 2.4 or later so I put has been kind of a 2.4 but has been sophisticated enough to say 2.4 or later yes it's that easy because in just like you can depend on this version just say at least as a version 2.4 so that's easy if you do use has been used in Python and at the packaging level you can address the requirements by just having a dependency on Python greater than equal to 4 and that will do so I will say it can you just finish what you were saying so the channel proposal I am not sure this is a good idea but the channel proposal will leave this would we have this thing not depending on its specific Python 2.2 dependencies but of course this one to depend all the way down you could automate that yes it's disgusting it's like it's one from the yeah exactly we've already had problems with that sort of behavior so I would like to actually throw it out there and you could have that automatically determine using the control fields and this to say that I obviously depend on this thing I need to support 2.3 in particular so I will depend on 2.3 being in Python so we could do that as well I'm not advocating that it is possible but the difference would be that this package would not need to be re-compiled when we change to Python 2.3 but that's now the best for me about this is only a countable part of what Matthias said so only for this part but you just call it out how much effort do you think would it be to Python 2.3 and how long it's already there yes the other side of that is you do have to re-build the application in Python 2.3 so you're still doing some re-building here just change what you look at basically you just have to change some of the functions which Matthias has to do I'm wondering how many applications really require a specific Python version if it's a small subset it might be an idea to not always necessarily provide Python 2.3 dash something but simply only provide Python dash by something and simply not support applications depending on a specific Python version but just the general one that works with the current Python version it would also make it totally unneeded to re-build anything and then you only need to re-build the non-binary module stuff up all the way to the applications that are actually requiring depending on a specific Python version well, I think it would be good at least to be able to this can't be about two people in the world and the application could defend it to be honest, the application is part of the definite archive so we need somehow to put an API when the other one is an assistant on his local system he writes in his own application that runs only with Python 2.3 and I think we need to support the second case any case but that doesn't need to be supported by a package assistant but the first case I don't know if you have numbers about how many applications do they have that are specific to a Python version or how important they are to their handle there are some today that probably shouldn't be done that way far, there are a number of packages today which because Python 2.4 is at the default maybe it's Python 2.4 my feeling is what we're diagramming here is the worst case scenario for the dependencies that we have to have something in mind for how we're going to support this but yes, the majority of them it would be great to not do the provides all and allow them to be demand-driven based on whose packaging what that actually requires specific versions so this is optional one disadvantage of making it optional is if you want to go from 2.4 to 2.5 or 2.3 or 2.4 you have all the modules built from 2.3 and then you want to go to all modules built just for 2.4 you have a huge transition that's probably done all at once if you have the modules dying to supporting 2.3 then you have some of them supporting 2.3 and 2.4 for example, more of them supporting 2.3 and 2.4 and by the time you actually do the conversion they're pretty much all supported by them then that's much simpler basically you don't even have a little transition it just goes in, you know, one by one which would be really great that's one of the reasons why I think we should do the dependencies even that's also why I think I don't really like the process that you did because I'm not saying I like it enough yes I do but I can never say to you you said that you liked it I just said that I didn't see you so I don't think I think basically because I don't think that we should use the the the the things that we should use the distribution of dependencies we're making this before that because it can do it as an iser than to force some packages to build all the dependencies to change in themselves that's why I'm feeling it's an idea I thought I thought it was better it's less bad I do not really see the problem for binary modules I think we do always need this 2.3-vitamin because they're binary modules and your binary component anyway so why not provide it and for non-binary modules I think each module package can be separately transitioned it only depends lower way down because the package is depending on it if they do not have a specific 2.3 or 2.4 requirement either the old or the new version will satisfy the depends so when the new version introduces a requirement for the new version of Python so you put the Python 2.3 application that depends on this binary module I'm talking about a situation if you do not have the application specifically for a certain project say you have an architecture all Python package which is only used by things which you use to be all Python version does that package need to provide and depend on the specific Python flavors or modules to be and then we don't have to worry about the use of artificial packages if it only has to use Python-boot the problem is it works well as long as you have a large food chain of dependencies it works well but now it's amazing that one of the packages deep down inside I make my package more easier by by a smaller c component than does it is this upload just starts to break all the data to it why? why is it pregnant? no it has the extension for everything but it doesn't actually provide the Python 2.3-2 when it provides Python-3 and happens to but now if you do what we discussed just before if you change the forward version then what it might be the Python doesn't be done yet so it's that much and we will know that because it depends on Python we're going to equal 2.3 Python less than 2.5 because it's binary it has to have a dependency on the correct Python versions and the same before it doesn't work if you say it's out of the city so the problem with that is that the packages that provide the Python 2.3 that Python cannot actually be used from scripts which we want that to be a original case anyway in the archive if there's no demand for it can we get away with that are there any other side effects it gives us the possibility of just saying yes we don't have to rebuild this binary L module for a transition at all if nothing is using it it requires a specific version it's basically what I think but these hopefully depends with Python bigger than 2.3 is smaller than 2.5 is then also not so though to be applied anywhere else or modules that use the same features from this version and actually this depending on something as small as that it's not as bad as long as there's a minor version difference it can be satisfied by two different minor versions like 2.3 and 2.4 it's bad it's already one minor version two is okay so we can transition step by step but then you have a problem because and to depend on a 3.4 provides you do not necessarily get the correct Python version we depend on Python 2.3 Python this depends because it's a provided package which might depend on which dependency is satisfied by Python 2.4 in terms of how it needs to depend on both that big bug in Python 2.3 or Python that's Python 4 declaring that it provides an interface that does not it depends anyway is range depends which one yes because it contains binary modules that are only usable with Python 2.4 and that's how we declare that I don't think there's any other way Python 2.3 or Python 2.4 and Python 2.4 then it does not properly provide a Python-interface only we depend on both so while yet it's range depends because if the default Python version 2.5 it will break this package it will not be able to provide a Python-2 interface it will not provide that modules interface because it will be out of that range so that's the difference it's in another context that's a question specific question yeah okay so now now who's what are you going to do are we agreeing that this is what we should be doing which viewing depends and provides this way what else are we doing here we need to have the control file we need to write it down we need to we need to check for it and the rest of it we write those when we have half the archive transition over and you want to do it together let's work on the Python supporting those fields Python support should still be pretty effective in this area Python support should also just work with this okay can we do still