← Back to team overview

canonical-ci-engineering team mailing list archive

Re: objections to uservice_utils project on pypi?

 

Hi guys,

I think gating releases on pypi is the easiest way to ensure we have
proper releases and distribution of a library. We could use lp project
downloads, but that's not supported by pip, which implies and filling
our pip-caches differently. Pypi releasing is easy and independent
enough

Anyway, I will be really brief about this because the "let's have a
utils library" thing is already a done deal and as a team we have to
exercise the right of experimenting. However, bear in mind that this
topic is already bringing all sort of problems and wastes we agreed we
would avoid, this discussion is completely side-tracked from what we
have to deliver next week.

Instead of discussing things that represent direct value to our users, as:

- How to make ADT wrapper/setups more robust ?
- How to deal with deadletter-ed messages ?
- How to survive and isolate broken workers ?
- Can we show results properly in the Dashboard ?

We are debating new and old ways to create rigid and artificial
development workflows to lock ourselves in a very dark and lonely
place where changing code is a burden that should be avoided ...

My personal opinion is that I'd rather copy the whole worker module
and run a full sed renaming for creating a service, and become famous
in the process as the "CI copy & paste clown", than invest our energy
and bright brains into something that we already know will end up
badly.

Also, let's not forget that we will not be praised if instead of a
delivering a functional and robust core-image-testing solution, we
offer a something_utils library to the world.

It's an honest report of what I am thinking, and by no means a
statement that I will not collaborate on this task. Actually, I mean
exactly the opposite, if we want to do it, let's do it quickly,
collect the benefits (less c&p) and assess the outcomes in time for
delivering what we promised in time.

Sorry for the ranting ...

[]

On Tue, Mar 31, 2015 at 3:56 PM, Thomi Richards
<thomi.richards@xxxxxxxxxxxxx> wrote:
> Hi,
>
> On Wed, Apr 1, 2015 at 7:03 AM, Francis Ginther
> <francis.ginther@xxxxxxxxxxxxx> wrote:
>>
>>
>>>
>>> Or if it's going to break the API, expose it as a new, versioned method
>>> instead.
>>
>>
>> Let's be sure to document a pattern for doing this in the developer
>> playbook. We'll need to define some criteria for when a method is in
>> development mode and can be changed vs make a new one. This is probably easy
>> enough to define as when a service begins it's life as a production service.
>
>
> I think there's a few things to consider here:
>
> The review requirements for this are going to be more strict than they are
> for our uServices. I don't want to scare people off developing new code for
> the library (far from it!) but the bar will be higher for new contributions.
> I plan on configuring tarmac to require two reviews, and (if possible, no
> 'Needs Fixing' comments). In the beginning at least I'd like to be one of
> the reviewers.
>
> We can certainly document common patterns in the developers playbook, but I
> think it will take a while for those patterns to become apparent.
>
>
> <snip>
>
> Regarding releases:
>>
>>
>> A dedicated lp project and inserting this into our pip cache(s) sounds
>> like the right place to begin. Publishing to pypi might make it a little
>> easier to develop against if we automate the uploads, but I can see
>> deferring this until we have a clearer usage.
>>
>
> Indeed. The problem with manually inserting into our pip-caches is that it
> tempts us to insert <rando version I built locally>, which is not
> reproducible.
>
>
> The more I think about this the more I think we should release to pypi. That
> way:
>
> 1) We get all our python dependencies in the same way.
> 2) We ensure we only ever deploy with a released version.
> 3) We release our goodies to the world, should anyone else want to use them
> :D
>
>
> I'm not sure how pypi handles groups of developers releasing somthing - I'm
> in the testtools release team, so I know it _can_ do that, I just have to
> figure out how.
>
>
> Cheers,
> --
> Thomi Richards
> thomi.richards@xxxxxxxxxxxxx
>
> --
> Mailing list: https://launchpad.net/~canonical-ci-engineering
> Post to     : canonical-ci-engineering@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~canonical-ci-engineering
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Celso Providelo
celso.providelo@xxxxxxxxxxxxx


Follow ups

References