<div dir="ltr">Hi,<br><br>> I think the goal of this split is well explained by Sandro in the first<br>> mails of the chain:<br>><br>> 1. Downstream packaging<br>> 2. Tagging the delivery properly as a library<br>> 3. Adding as a project on pypi<br><br>Not really, because (1) and (2) are *a consequence* of the repo split. Not a cause. Please correct me if I'm reading wrong but he's saying:<br><br>- I want tarballs<br>- To produce tarballs, I want a separate repo, and separate repos have (1), (2) as requirements.<br><br>So this is where I'm going: producing a tarball of pyc does *not* require a separate repo. If we don't need a new repo, we don't need to do all the things that a separate repo requires. <br><br>Now:<br><br>> OpenStack provide us a tarballs web page[1] for each branch of each project<br>> of the infrastructure.<br>> Then, projects like Delorean can allow us to download theses tarball master<br>> branches, create the<br>> packages and host them in a target repository for each one of the rpm-like<br>> distributions[2]. I am pretty sure<br>> that there is something similar for Ubuntu.<br><br>This looks more accurate: you're actually not asking for a tarball. You're asking for being compatible with a system that produces tarballs off a repo. This is very different :)<br><br>So questions: we have a standalone mirror of the repo, that could be used for this purpose. Say we move the mirror to OSt infra, would things work?<br><br>> Everything is done in a very straightforward and standarized way, because<br>> every repo has its own<br>> deliverable. You can look how they are packaged and you won't see too many<br>> differences between<br>> them. Packaging a python-midonetclient it will be trivial if it is separated<br>> in a single repo. It will be<br><br>But create a lot of other problems in development. With a very important difference: the pain created by the mirror solution is solved cheaply with software (e.g.: as you know, with a script). OTOH, the pain created by splitting the repo is paid in very costly human resources.<br><br>> complicated and we'll have to do tricky things if it is a directory inside<br>> the midonet repo. And I am not<br>> sure if Ubuntu and RDO community will allow us to have weird packaging<br>> metadata repos.<br><br>I do get this point and it's a major concern, IMO we should split to a different conversation as it's not related to where PYC lives, but to a more general question: do we really need a repo per package?<br><br>Like Guillermo and myself said before, the midonet repo generate 4 packages, and this will grow. If having a package per repo is really a strong requirement, there is *a lot* of work ahead, so we need to start talking about this now. But like I said, it's orthogonal to the PYC points above.<br><br>g<br><br><br></div>