Cloud Native Buildpacks Working Group, 15 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Working Group: 2020-07-15

Description

* KubeCon EU Project Pavillion
* Inline Buildpacks: https://github.com/buildpacks/rfcs/pull/86
* Application Mixins: https://github.com/buildpacks/rfcs/pull/87
* Multi-API Lifecycle Descriptor: https://github.com/buildpacks/rfcs/pull/92

A

This is a Salesforce meeting.

B

B

B

B

B

Small group today.

B

A

B

It's not a Thursday, no.

C

The people, maybe two minutes to show up first, do.

A

We lose them between leadership in this meeting.

D

He's coming he's just trying to merger gnarly, specs I.

A

Like this API interface for respect, always thing, we've done.

A

A

C

Should we wait for bed get started.

A

C

Reminder to sign in to document if you haven't already I, definitely think there are more people here. Then that list.

C

And I don't think we have any new faces at this, so we'll skip that release, planning and updates.

C

D

Just got a patch release of the life cycle life cycle, oh eight, one that included its two fixes wander. We delete an old cash engine, even though the new image hasn't changed and therefore we're deleting the only cash image. The other one was how globs in slices handle symlinks and some permissions edge cases on slices, that's out, and then the next minor life cycle really should be. In a couple weeks. I was in.

E

No real updates from the platform set of things. We are looking into Tecton right now in updating the task, probably splitting it into two one for the creator flow and one for the different life's, like yeah phases, broken out after that we're gonna try to analyze, see if there's more, we can do with different phases, but that's the plan.

C

Awesome I, like the approach of having both templates, get the simplicity and the security.

C

All right, any other release updates.

C

I'll, do our ten minute RFC review as quickly as I can.

B

One second to share my screen.

B

Basically, that.

C

All right layer, origin metadata, is a draft so skipping over that packs some commands. This looks like one submitted a week ago by Xavier any past few updates on this. No.

E

I was out on vacation for a bit, but if it's worth discussing, we could add it to the agenda. All.

C

Right I'll add two in there. If you want to try it by this week, cool multi, API lifecycle, descriptor Emily, put.

D

On the agenda for today, awesome.

C

Experimental features Joe on.

F

The agenda awesome.

C

Cash scope, Xavier I.

E

Think that's in FCP I haven't seen any updates. Like I said, I was out any.

C

Actions to take oh.

B

No, this was not.

E

The FCPS, the other one, sorry, this one I think has to be taken back for some reconsideration. I, don't think the idea overall landed well with everybody cool.

A

So we'd turn that to draft or yeah.

E

I think we could do that just to skip it over until something better comes about I'm.

C

A convert that right now, yeah I.

B

E

Under the reviewers tiny little text, they're going right to draft all.

C

Right there we go and application Nixon's is on the agenda. Correct yep, inline bill pics seem readwrite platform volume out.

F

That's mine, I haven't gotten back to it yet so you can skip it. Cool.

C

Offline build packs, RFC Dan is officially going to be on the VMware team that contributes to that interval text project. It will implement this once it gets through, but he is still he's on another project for about a week before he transfers over. So maybe a little bit of time before he gets back to this. But that is the first thing. He's gonna work on I. Think after the transfer, RFC pack image pull policy have here, that's.

E

The most amazing P yeah any.

C

Action to take seven days ago that.

B

Means merging I'll take care of that just.

C

Closing 25 July, it's.

F

Just a typo, it's like 15, okay,.

C

All right add RFC for stack metadata, I, don't have cash here, but I thought this was. This was ready to go yeah.

A

I talked with them last week and submitted a suggestion which incorporated like.

D

We have enough approvals, the FCPS.

A

I think the only thing was we just need to get the DCFS because github plus GZ, oh.

C

Cool I think it's just missing my thing and I've already looked at it so I'll and then yeah at CCO. So.

A

I feel like we just move doing.

B

A

C

Got it you told me nope.

B

C

Rebuild Peck as interface for app extensions I'm. Sorry, that's a draft RFC for customs. He has a draft image, exposes metadata for all layers, participating image, build.

B

C

Guessing this is superseded by layer, origin, metadata draft.

D

C

All right, we are done less than 10 minutes.

C

Next thing on the agenda: first of many RFC's to talk about today. Oh no sorry, project, pavilion.

B

So this is me as part of coop Connie you, which is coming up shortly. We've been offered a chance to participate in the project pavilion even on the leadership team. We're a little bit unclear what exactly this means, but our current best estimate is that it will work like a virtual office hours if you've ever been to a conference. It has office hours. Basically, you make yourself available and people can come and just ask questions about your particular project.

B

The leadership.

F

Team is doing other things like talks.

B

And stuff like that, and we were wondering if any of you who are sort of thinking about going towards maintainer or just general contributors, would like to actually staff that booth and answer questions for the community about this stuff. So we threw some names in there as suggestions, if you're interested we'd love to hear it and love to put you out there, it's kind of like public speaking without anywhere near as much prep time, I.

C

Submitted the form with the first option, so we're set up to be able to do it, but I'm looking for volunteers to help out.

C

So please reach out to me. If you have questions about it or or you could volunteer here, if you're interested do we.

B

Know what the time commitment is I think.

C

It's just beyond slack for a specific period of time. Yeah answer questions and provide links, yeah.

B

Again, like we don't have a lot of visibility into this, but if they run it like an office hours, it's like an hour kind of time, commitment and again no problem.

A

B

Just need to go in there be able to answer questions, but it's you time right. So who knows when that hour is I, guess yeah sure I mean I would hope that there would be a good at scheduling it I when I just looked the cute guy here, I was worried too. It's the entirety of you know like all four days, no an hour I'd be happy to do say, but don't hold us to that. But.

A

That's the that's the theory we are all working under and are free to reevaluate. Once we know boy.

D

Maybe this is booth at the expo hall, whatever that means I figured.

B

They were like totally revamped the schedule to make it all just a build, packed project pavilion for four days.

A

Recommended and probably being the key word like I, feel like we.

C

A

B

A

Mean we could do whatever hours you want I, think, but I think this is one it will be open whatever. That means virtually.

D

Yeah more than one hour, we.

C

Don't even have a confirmation that there is a slot for us or anything, but the forum was like if you are interested express interest here and we'll get back to you and tell you that you know you can do it, and this is how you have it set up, so not really much known about it, just if you're interested in helping out in any way for any amount of time. Please let me know.

C

Anything else with that, if not we'll move on to inline bill pecks.

F

Sure the doc so I think we're really close here. The outstanding conversations about the Tamil schema and Terence had a proposal here which you can see which I wasn't too hot on but like I, also don't care. I think this is fine.

F

I kind of just wanna make a decision and move forward. I also agreed with Steven that the the key should be in line and the table should be something else, but I don't know what to call the table so I would love help I, think I'm, basically just burnt out on this, like I, would love someone to have an opinion for what this should look like, but I feel like neither Terence or I kind of want to die on our Hills.

F

So if I don't know, if.

B

F

Has suggestions fire away.

C

If you swapped I would approve, if you swapped a script for inline and then picked a new name for the top, but I have a preference for not having the double table structure because I think it's harder to parse, but it's not a preference where I would not approve. For that. My only blocking thing is just in line.

F

Yeah I feel the same way. I definitely acknowledge the reason to have the table, but it doesn't solve the I mentioned this up here. It doesn't solve the conflict between your I inversion. So we'd still have this like. When do I use the table when do I use URI inversion, like I said like even with the table. This is kind of a mess. This example here is kind of a mess.

F

So yeah I don't know I.

A

Don't you never actually use version or your I? Do you when you're doing in line right.

F

Yeah yeah, what I'm saying is what takes precedence here like that's still a problem right and even if you moved version- and you are I into like some other table like then, you have multiple tables within the build pack. Build packed stable, so I feel like there's still a lot of like I, don't know when to use each thing kind of problems.

F

A

Me version your eyes like an optimization for the common case. I think said that might comment yeah, it's like. Ideally you do it cuz. It's like you want to make the nine percent case the 99 percent case like easy to do where the other one is like a thing that is not rare, but uh a little more explicit for doing it. I mean I'm, not gonna, Don, that hell if everyone wants to get rid of the table, but also don't find it as ugly as everyone.

A

Thanks to this, maybe I've written more in Tamil than more of the people in.

E

That example, the one on the top. There is a mistake there right where the API is in the wrong section. Yeah.

C

The one on the top shouldn't a PI API shouldn't be associated with the individual, build script right. Oh.

F

No, it should be, it should be like this yeah.

E

It should be in the inline section you.

A

Can't you can't override the API of a like of an existing Bill pack.

C

Right: okay, it's the face and lion still confuses me. There.

F

Yeah just yet a suggestion which I don't like what I thought was worth bringing up in that, like the build pack gets sort of defined outside of this table, and then you just reference it by ID, which is I, think I, know just kind of clean, but then I we have a new top-level key and it's kind of this like layer of indirection. That I think is also confusing. So just thought it'd be worth sharing.

B

D

Like that suggestion, thank you fine it, and then you put it in the order.

B

A

Turn there it's like yeah.

B

That's it's like all defined in the build pack, so it's a weird one for anyway, like once, it's all being defined anyways in that file. It maybe I'll just condense it more yeah.

F

If we had a strong use case for like using that in mind, build pack twice I'd be all in on this, but I actually think that unlikely impossible.

C

Probably because he can't have two the same tool pack in the same felt right yeah. Unless.

E

You declared different orders, but that seems I do.

B

It unreasonable.

E

B

Referencing the same build pack and like multiple groups, I, don't know like. Isn't that a case where you would want to define yeah.

F

But not in the pic.

B

F

Yeah not in in build pack or in project project.

B

Tunnel yeah there's your like: could you define just an inline bill pack in your project tunnel and then reference it in a different order by by giving it an ID from like pack, you could specify build packs in kind of whatever order you want to kind of override the the builder defaults and kind of put your build pack in between other build packs that are in the building.

B

Without necessarily defining the order in the project, tomahawk cuz, you don't have to have build, build packs in your project tunnel, but you could still define build packs in line to kind of pin them to the Builder. Essentially.

E

But the project tamil, the the order in which the wolf packs are defined, is the order in which they are executed right.

B

But not if you have just built backs in line, if that's not meant to be ordered, then you go outside merge them together with things that are come from the builder you our eyes, as well as in line better to find in your tamil president on well. It's.

D

True, if you're doing pack a build with the build pack flag and therefore you're overriding the order, if we only define it within the order, does it then become impossible to use I.

F

Mean you can also just modify your project tamil I suspect like at the point that you're passing options. Well, no I! Guess you could do something like have it configured one way on see, I added stuff be really weird. I, don't know it's like if you're passing the bill, packs flag pack, I can't think it seems like you would have control of project Tamil. At that point,.

E

F

It's not seeing a use case in.

E

Which you want to use both of them, the project Tamil and he bill pack, flags I'm, not even sure what would have I've been right now know.

D

Like, let's say, I have a order in my project. Tamil and I want to replace one of the bill packs with another water, but still use the inline pill. Pack I might define.

E

D

And replace one of them, but I could want to do that for as a convenience without editing the project. Alright we're in a CI where I'm building a little bit differently, but.

C

I, don't know if that justifies pulling the gold pack out into a separate location, because you could still reference it using Drive build pack by ID, even though it's included order. It would only be a case where you don't want the default to include the build pack that you're, including in the app which may be a use case, like think of something like. Oh it's an optional build pack that you can throw into the build that the app provides. Then it would make sense to reference it outside of it.

C

But if we, unless we think that's that's practical, it may.

D

Be the app could provide different in-line, build packs that you swap out, depending on how you're running in you know, yeah.

B

D

Some ways that makes sense to me because the list of bill packs are always to look up other build packs, and this is just another bill pack. You can look up in the list. It fits together logically.

A

I do have some I can't really.

B

Meet the guidance of like kind of what you were after right, like a really simple, like you know, a couple keys to get a built pack to run so I definitely understand it's not really in line with that. If we.

E

Support ended or not intended I.

B

Wonder that Elsa.

C

If we support inline, proper inline bill packs in the or build tax list, then later we can support a separate location where you can define them and reference them and like it doesn't go in the simple way where it's not referenced doesn't preclude us from referencing in the future.

F

Yeah, so with that, what if the like the way, Terrence described, URI inversion as like the shortcut sort of I came over the word to use, but it's something like that. You know the.

A

F

It's like a phenomenal price right, yeah like what, if we included in line such that version, URI and inline are mutually exclusive and then API and she'll have defaults. And if you need to specify these, you would need a separate table. But if you just want to put the inline, you can omit the others that doesn't have enough that works for API. It seems like that'd, be a problem.

F

Like I was going like, we need to have just a single key and then the table for all the other structure. If we wanted.

C

Leaning towards Terence is suggesting that it be broken out to a table down.

A

C

Because that way, there's a single key that indicates that the behaviors is gonna change drastically to reading this particular entry. As you know, this is what's providing the functionality and.

E

Then, from defining a schema, it makes it a lot clearer to write where it's not conditionals, based on what you're trying to achieve. It's just hey, provide this object, and these are the required fields within that object. So.

A

In Joe's example, this is just an error case right. This.

F

One up here, yeah, we could define I would probably say an error, but we could also just do precedent. We're like, if you are I, is there it just takes you a ride and ignores everything else, but I probably are I.

B

D

B

Sorry good, if.

D

We're gonna make an inline table. Maybe we should actually put ID in there too. Somebody's.

B

Just gonna say: yes, Jesse suggestion, because.

D

You're in lining the whole thing, if you pulled it out, then you can reference it by ID, using the normal ID field.

B

E

An empty object, above that so no other properties other than in line. So what you're saying.

D

Yeah so in line version you are, I are all mutually exclusive.

D

What is I think it's less confusing cuz, there's less overlap, you know so.

B

D

B

Like Joe's suggestion 90 days ago, of the build that built packs and then right underneath that build that build paxton line now uh bit above that.

E

B

Years ago, yeah that one like is that what we're is that were you're suggesting Emily, like every key just being said in line yeah.

A

Yeah I guess I only pulled ID out because it was the only key that was common between that's. Why.

B

A

B

If we put the ID in the build packs table and then instead of build up, build packs in line, it's build up, build packs dot that ID, you kind.

F

Of get problem.

B

F

Sweat the ID couldn't line. Oh yeah, that wasn't say you can do this in Tamil, but it's really awkward yeah.

B

Bit tell me awkward if you name it weird like if it's gonna be in mine anyway,.

F

But they're all gonna have a slash yeah.

E

We got pushback for this on something else as well right, cuz,.

F

Not logged in here, but it's like dot quote and then the ID, unquote I think yeah.

A

You can just use strength straight up strings as a key I. Think. Yes,.

F

I, don't know I, don't I, don't want to talk about this anymore, fine with all of it and just I just want to pick one I guess like.

E

I just want to implement it encoded right, not decide, then.

B

Do that Joe, you decide you're the decider, but.

F

I can't decide I.

F

B

F

So let me just one more one more thing: I want to drill into the ID in I. Don't know, I, don't really know which table it should belong in. It feels like since there's already an ID here. It should be here and I didn't understand the reasoning for having it in the in if they got the name for inline, but like it, I didn't understand that logic for having it in that table. I think.

E

It just makes it look better and encapsulates everything that's necessary into just one object.

B

You're, imagining.

D

That you could pull out the in line into a different table and then reference it from within the bill. Black bill, Plex you'd reference it by ID, but you still need the ID and the in line to reference. So in this place it's like really truly inlined the whole thing. The whole definition you would need, if you pulled it out, is just in lined under in one like.

C

The ID field has two meetings. One meeting is I'm, defining a bill pack with this ID and the other meeting is I want to use a dual pack with this ID yeah.

D

F

Right, I'm gonna, put a pin in this I'm gonna, put together the options and spell them out one by one. I think I understand that and then either I'll figure out either well, just like take a popular vote or I'll decide, but I think I think we're just kind of whipping a dead horse or something sound. Okay, yeah. It sounds good.

A

F

Right, thanks for nothing.

C

Next on the list is applications.

E

F

C

F

From I change this from draft to real PR and it is complete in the sense that I have addressed all the things and one way or another, but the the things that I think folks should look at is your reira viewing. This are I, don't actually have a use case for detect phase we talked about. Potentially it enriches the mix-ins that it provides with some more detail like I. Have this bias where I want to keep detect phase four stack packs, but I just don't actually have a use case.

F

The reason I want to keep it is that I think they're, a special case of rebuild pack, which we would define later and I've tried to call that out in the air and the our proposal as well see that root pack is a thing. It has a definition and in the document and everything the next one was I made it clear that the stack packs are included in the stack image like prior to creating a builder, but that the Builder sort of enables them in your builder tom.

F

Well, you would have like stacked up bill packs or whatever, but it just assumes that it's already there that, like the alternative, would be that the builder tom wall knows nothing about them, they're just there and they run or something like that. I don't know, and then the third thing is I. Had this example see a cert build pack and I'm using mix-ins to sort of turn that build pack on and I've expanded the scope of mix-ins.

F

To do this, where there's like a type equals, see a cert and then followed by a path to a file. So I know that's gonna be contentious, but take a look at it and I. Think it'll requires some back-and-forth.

C

Should that type equal, CA certs in the mix-ins list in build pack Tamil that rook says that the app require or that the other build pack requires those mix-ins I guess be regex that says type equals see a certain colon and then some stuff after that, or are we making type equals a special thing in the API it's to find outside the stack former.

B

C

So it's just a mistake. On example, see a circle: Peck mix-ins equal should have regex. It's alright.

F

We're we're here.

B

F

Yeah, oh sorry,.

C

I didn't realize you're sharing, yeah.

E

So otherwise it's a static string right, no.

C

I seriously yeah yeah yeah.

B

C

Wanted to make sure type equals wasn't a special thing in the API you're just saying a stack could define type equals to mean something, and this is a way that you could use that, and then we can go back on the Bionic stack and say your time. Peoples has this meeting. It sounds great. Oh really,.

F

A

We have to update what yep this currently is not valid. On my own.

C

But as long as it doesn't as long as that type thing isn't something we're adding to the API. It's still just doing a regex.

B

C

On the Nixons, and then it fits in nicely it's a build, build back so that the Nixons in build pack tamil is where you say what mix-ins that you can pro statically say what mix-ins you can provide as a build pack. Is that right right, that's like normally that would go and detect, but we need to do it statically, and so it's going to be defined outside of there and we can put it on the outside of the image McNew. That's something you would ask for specifically. Do you have any thoughts on that.

B

Though that aligns with what I was hoping, we didn't able automatic mix and list.

E

So I am curious in regards to the mix-ins being regular expressions or the possibility of them containing regular expressions. This right now applies to for one like this applies to this stack, build packs or your app mix-ins. Would it also then apply to the standard build pack mix-ins.

F

The ones that are required by a build pack- yes, is that what you were asking like a a standard build pack cannot provide mix-ins, but it can require a mixin I. Don't talk about that in this in this proposal, this is about the app mix-ins, but I totally I may even kind of mention it. But I expect that that would be the case. I might actually just hand wave and say that, like the stack pack is gonna get a list of mix-ins and you know what I mean wait.

C

You're not to find any interface for another build pack to require mix-ins. In this there.

B

C

C

B

That mean it at this time the only mixes can be provided, be a project tunnel.

F

Require required yeah.

F

I'm happy to try and flush that out I think it would be done with bin detective a build pack, because we want it to be dynamic. Yeah.

B

C

Would at least put that even if you don't define the interface I'd, put that that's the intent? Okay, because to me that's like the really powerful feature here. It scares me also, but you know.

F

Right and what I didn't I know what I didn't want was for build packs too I didn't want this mix-ins in bill pack tamil to be like. Does it provider require it's just always what it provides? So if we do the requires I think it should just be part of detect to the build plan or both, and just do that. I think that also addresses your concern. A little bit, Stephan I feel like it's less likely to be abused.

F

If it's part of the build plan versus built back tunnel.

C

It the currently build pack Tamil has a Stax list where the build pack can specify the Nixons. It requires on the stack right like it.

F

There's another.

C

Mixing section in there this top-level key is going to be about mix ins that the build pack provides, as opposed to mix ins, that the build pack requires from the stack when another build pack lists. The mix ins they require in their stack section cannot be satisfied by a yeah.

F

C

Stack pack is my first question. The second question is: what's the meaning of mix ins can I, can a stack pack itself require make sense in the stack link or can another stack pack satisfy the text provided by that stack pack? If the other stack pack is before it.

F

I've thought through this very deeply and yes on on both of those awesome.

C

I, like things when I put, the call you out of there, is.

B

Ever a time, a stack pack would only provide certain mixes a certain stacks or were to stack back, always be able to provide this a mix and set for all stacks. That works with.

F

In my proposal, I can't do that it has to be the same for all the stacks.

C

Is it worth kicking having to pushing the mix, ends down to the stack section and having to because I think you'd want it? You'd want different reg X's, because different stacks might define their type things differently right. Should you should we push mix ins into the stacks list and then have to mix ins keys in stacks list, a required mix, ins and a provided mix-ins.

F

Yeah, that's kind of what I was trying to avoid, but that does make sense. Sorry why we try to avoid it it just. It felt like a simpler interface.

C

It's not that we could have that list at the top level. Also, that built under the build pack section also and then apply those to all stacks stack, specific ones, and then you, grass and complexity.

C

If you wanted to yeah all right, sometimes I feel like we should support, build packs that don't specify any stacks like four pack file up kind of one of this that just run on all stacks, and you know you better know that it's gonna work or something, and so you know like makes me wonder if we should support more things like that, I mean.

A

Could you just specify stacks I equals star or something as a special case yeah? That would work too.

B

A

I think the pushback for provide requires is every time I've had to introduce that concept to a new person. Looking at it, it takes longer than one would think to explain like what the difference is like on the surface. It sounds simple, but it is there's like more than it wants to. It then I think initially Lisa in the bill plan right.

B

Health plan document took a long time because it was there's an unclear concept to explain.

C

We could keep the existing mix-ins key to just continue. The meaning of these are they're, quiet, mix-ins and introduce another one right that it's more explicitly named to so you can avoid the terminology, if that's a confusing part.

F

Yeah, we can also add that later I think if we decide when you did like it like nothing in this proposal, prevents adding per stack mix-ins.

E

Since we're adding regular expression pattern-matching to make sense, I guess are we concerned with having escaped certain characters when trying not to fit into that criteria?.

E

Because right now, these the make sense is arbitrary strings right and so technically some of that could fall into a regex pattern. Matching.

B

C

Should carefully define whether the mix-ins are regex or not, I guess yeah.

E

And I think that's really it right. So if we say now going forward, mix-ins are regex patterns. Then yes, you're forced to escape characters on certain things. This time, we'll.

F

Have a regex thing.

F

Be nice if there was like a are quote pattern: I.

A

Feel like any time we dropped her regex in the strain it makes me feel like I wish it was an object. It's that.

B

So what is the use case behind making.

C

Mix-Ins reg X's again because, like.

B

I thought they were mix-ins were.

C

B

Predefined, like Ubuntu packages generally like what is the case for having like non set.

C

To find mixin these cases that I build pack like the real, the new relapse, build packs can actually advocate, install as route isn't limited to providing its on the provider side, not the require side, and it's that building isn't limited to providing this package or this package. For this package, you have to put every single a buncha package for eight. You know four in that list, so instead you can provide a regex that just says any mix, and anybody who requires a mixin that matches this pattern.

C

I can provide that and so the build couldn't succeed and it can be defined statically so that we can build it's.

D

Interesting about that is when we think about the CA certs as I mix in like if your pattern, which is everything that would match, but that build pack can't maybe isn't the bill pack that install CI serves like I. Don't know how you I should get a pattern that only matches have been two packages and not other random things like. Maybe we should double down on just type thing and then I said having rhetoric says it provides type package.

E

The proposal for the apt, mixin or build pack would be that it'd be prefixed with a BT. So in this example, that's been displayed here, yeah you're right, but if it had like prefix of a PT that would fit that criteria right, not.

D

Saying yes, change all the mix prefix with a PT.

C

Yeah I, don't think we'd want to change the existence. What that that regex right there says is that it because we fer bionic, we've defined a package that doesn't have the right mix and it doesn't have the equal sign in it, as necessarily an amped package name, and if it has the equal sign in it, it's not an app package name. The app build tech can completely cover every mix and that's an app package exactly with with the regex that just says things without equal signs of it.

C

So it should be sufficient without the a prefix.

C

Now whether that's the good interface for solving this problem is, it may be a different question, but it is per stack. It's not defined in the API, so another stack could use the app prefix or some some other package specific prefix to define its make sense. Instead, the.

B

Regex is defined per stack.

C

The meaning of mix-ins is defined per stack, the meaning is defined okay, except for build :, it run :. Those are those are defined universally.

C

B

E

Like regex, because it allows for a lot like that, Swiss Army knife, but at the same time, I kind of see and agree with the type that's being more user friendly, I.

A

Think I like and dislike it for those very reasons, ok, I I feel like you can get down a pretty messy. All supporting regex is for sure in the long term, but it's nice to have that flexibility in there in the early days can I think like Ben's pushback too, restricting the build plan. It's like. We don't exactly know how people are going to use it. I.

C

Think I would go with objects if we didn't already have lots of build taxon stacks that use a string base listed, make sense.

A

You is this the thing you would want to fix going into one out if you could wave a magic wand soon, I would.

C

Not hold 100 on changing the interface from what Jose proposed here and I would be okay, going to 100 with this interface, because I think it.

C

The object would have to be relatively complex to cover things like what, if you have a build tech that can install you know, nixon's for both or just like, only build mix-ins for the selection of packages, or you know like I, like some of the flexibility there projects and it would probably be complicated to find out with more structure I think we could do everything we need to do with the regex I.

C

Don't like how it's kind of unexpected that the providing side of mix-ins is a regex. Suddenly right, I can very easily see someone put a drop, a mixin name. There, that's happens to be a regex, and that feels like a loaded gun.

B

It gonna be weird for the people writing a stack back that they have to know that type equals is something magic to get them out of like after package territory.

C

It's only magic for the stack for, like the Bionic stack.

B

Okay sure but yeah.

E

So this means, if you're trying to can yuan meant stacks like that Bionic stock. If you wanted to provide additional mix-ins, is that maybe what Justin just going into and if you wanted to add a different label, an additional label to this I still satisfies the overall Bionic I.

B

Was just kind of thinking just usability if I created that see a certificate build pack, I would have no way to know that I'm supposed to put type equals in front of CA cert, like my gut for mix and as soon as I learned that that's my key I would just name it. Something and I wouldn't realize that, like the stack is gonna try to like app to install it.

B

If, if that's a root bill, Peck that exists like you just might, if I, if I name that curl, that act is gonna, install, curl and then mine's also going to I guess not get curls depending on the order right. It's not because it's already gonna be provided by the app package, one in that case, I.

F

Think, though, like because the types like the type is kind of local to the I guess to the stack, so it's I don't know, it doesn't feel like a huge leap to me, because it's not like we have this secret list of types that is defined in the spec, and you have to go. Look up.

F

It's just sort of what you've established as a stack provider yeah and like the person not like the person providing the stack pack is also the person providing the stack who should also know about the types like if you're providing the Boone 220 ID you would. You would know that type equals cert is a thing for Ubuntu 20 or if it's Bionic, if we added to Bionic I, guess.

D

That's what worries me about the regex honestly is that for a different stack, where these things were defined differently, it'd be really hard to make a regex that only matched packages right. Sort of the fact that this can work for us is because of the Bionic stack, particular definitions. That's.

F

True right, you're saying that if we that this basically doesn't work, if you change this to a different sack, yeah.

D

F

The equal sign is specific to Bionic yeah. That makes sense like.

D

If I had it'd be very hard, try to render the only match packages unless you specifically yeah.

B

It's just a knock against really want to type I think am I somewhere on their other.

C

Stacks to use more clear, designation for packages, then then you know it hat doesn't have an equal sign in it. Like we chose for Bionic right, another stack could perhaps more saline to find packages as it starts with pkg : right and then you'd have a regex that would always match those things. So I don't think it's a to mean it's not the thing against regex. It's almost like the worst problem is how we defined a bionic stack. Nixon's, not you know in a very loose way.

C

Not that mix-ins are, you know too, are too inflexible, but sorry not that regex is too inflexible and tool to solve the problem. I think.

A

The complaint is that reg X's are too flexible the tool to solve the problem, so you have to understand more, whereas if it was more restricted, it would be potentially easier to reason what I do empathize with Jesse's point of like yes, the stack out there defines the stuff but like if I'm a stack pack person, because that the implement I think for work. It just means out to know more about a thing and understand, like these details, probably more depth than if it was more intuitive or something I.

A

Guess it's kind of the point not that it's impossible to do. I.

F

Mean I feel like you have to know something, though right like if it's not type equals it's a list of certs somewhere.

C

I think I generally agree with that.

F

Yeah I get I, get something: I, don't disagree with you, Jess yeah, it's just like I, don't think! There's a world where you don't have to know something along these lines.

B

A

I guess just the project table mixin thing feels like that. It's super gross, like string hack of like I'm, trying to pass input. Then oh, this.

F

Town here you mean yeah.

A

F

Know like it feels very like you are in ish, you know like got this like qualifier and then that's the path like no yeah.

E

The you are eyes definitely came into mind when looking at that I was like.

B

E

We just be defining URI schemas that going to make sense, yeah.

A

Has a whole RFC around it and to me that's like not a feature.

C

Maybe if somebody wants to propose an alternative way of providing and requiring mix-ins that is backwards compatible with the existing mixin structure in the RFC, like it I feel like we're, not gonna yeah. We understand the problems now right. We understand the decision to make and be up to somebody to propose an alternative that didn't break the existing structure and provided the same functionality in order for us to be able to change it before we do about that. Seem right, I'm good, given we have 8, we have 8 minutes left we could do.

C

We want to I had want one or two more questions about rebasing, but I don't want to. You have all the time if the other things are still in the list. What we have left today, I've.

D

Been trying to get this on this next one on the agenda for the last two working group, so maybe we do it real quickly.

D

So we emerge in RFC II. That says the last cycle can implement multiple.

D

Api it's different platform built by kpi's, but we need a way to describe that. Both the life cycle needs to describe what it implements so that when PAC is creating a builder you can set the right values and builders need to be able to describe what sense of API to implement our current life cycle. Descriptor only has one field for each of the api's, so I'm, proposing a new descriptor file that basically has sort supported API.

D

Some different types, there's like the supported range is everything between min and Max, and we have deprecated, which are everything between a deprecated min 2 min, not including men and they'll, have experimental api's, which means we could provide opportunities for people to try out a new API as even though we haven't cut the spec release. Yet we don't make any guarantees about those moving.

B

D

E

Think I'm only seeing your the pull request list.

D

C

Mouse is moving around as if you're selecting other things.

D

I'm glad what I was showing was a pull request list and not some other random screen on my Angus.

D

Alright, let's try this again, not.

B

Your working group stack ranking list yeah.

D

Here is what I guess.

D

So replacing our old a life cycle, Tommo file with one that allows us to describe more things about api's and then applying new Able's both to lifecycle images and to build. There's that describe these api's.

D

There are some details in here about when people are using something the deprecation range weather will warn or fail or be silent, and then for backwards. Compatibility I'm, proposing that we leave the old label with the api's and just set it to the min of the supported range so that we can get people time to transition before we take it out.

D

D

C

At the initially proposed schema there with a max version in the men version, it kind of feels like me, we're working around the fact that we are still at point something versions and we don't have cember semantics in order to suggest when a change is breaking change and whatever, and that we're hacking around that by specifying exact versions where the breaking change starts and stops.

D

Yeah, it gets me a little bit awkward. Let me get into one oh, but I would say when we're transitioning, like I, can imagine role we're supporting oh five and one two, and then we are still supporting everything in that range like yes, that API had breaking changes, but the lifecycle is still gonna support both of the api's. If that makes sense,.

A

These are all just valid, basically inputs into that band bars right, foresee any platform. For instance yeah.

D

A

Can specify a thing between 0.5 and 1/2 in that example, and we just said yeah.

D

So like when we get to the one O's like if we support one seven like we also support one, oh by definition, this run allowed to make changes in one seven that directly conflict with support for one off. So then, maybe this weird range scheme uh starts to feel stupid. Let me get into the ones, but I do think. We need something like this to get us through.

D

I, don't read it twice, though, so, if we do think this is gonna feel stupid. Eventually we could try basically open to any any formatting of this file that solves this problem. In.

C

My head, if we're following sunburst semantics and we were past 100, the way to specify the things that the lifecycle provides, is a list, a flat list of versions that are like 1.3 2.5, and that means 1. Everything in the 1 range up to 3 right and everything in the 2 range up to 5. Right and there's.

D

Originally proposing this on slack the xavier at some point, who sort of put the idea of ranges in my mind, but I think well, I like that, for the post 100 world best, it doesn't actually solve our problem now, right now like we could just change our single API pre 1 out to be like. We can move from. Oh three, two, oh four, and we could count on platforms to know that oh four means. Oh four and oh three, but not o I. Think that's a little bit much to ask and.

C

We can we say eventually. This is what it looks like and here's the schema for that and then have a special extra field in there. That's like called pre one and then have this format inside of that field, and you know just just so. We have a path forward and it's clear to everybody that this is a schema. That's gonna go away post one. Oh, maybe.

D

What we can do is actually just provide a list and then pre one. Oh, that list is long because it's got all of these things in it, but post 100, it's less long, like post 100, you could have you know oh 7 and 1/7, and that means oh 7 and 1. Oh, throw 7 I like.

C

E

I have a couple, maybe questions that might answer or help at least guide that conversation going forward, but it seems like commonly yeah like you would have a range of min and Max I am like dubious on the deprecated and experimental versioning specifications trying to figure out how they plan and how important they are to this concept right. So like the deprecated.

E

Could that not just be incorporated in the min and anything that isn't the max just be? You know in some sense deprecated.

E

Like why the differentiation of what is deprecated and what? What is below the you know, current state or max I, think.

D

Of deprecation api's, as long as we want to drop support for us if you start printing ugly warning, so people are forced to upgrade I'm, not sure that every time right now, when we introduce a new one, that I necessarily think we should be automatically deprecating the old one.

C

Could you do a list of supported versions with the semantics? So if it starts with one, then everything below them applies, but pretty one. It has to be exact versions and then have a separate list of deprecated versions with semantics of, if it's pretty one. Oh, it means this exact version is deprecated. If it's post one, oh, it means I, don't know what that means exactly.

A

We could figure out later. It means like one out up to that minor version or something right. It's a like say the.

D

Rules we've put into the spec basically say that one, oh, it's a subset of one six right, so I, don't think we'd ever deprecated one! Oh! If we still support it once things, you don't do any ganda to that. Deprecated. The one-line right.

C

In the deprecated list it would be point something point something and then either it post one. Oh, it would just literally be one or two I think is and.

D

Then I think experimental. This was something I asked him. The questions I feel like you should always be exactly one I, don't think we want multiple experimental. Yes,.

E

And could you elaborate on what experimental means in this context, it's.

D

Like and usually the next API that's going to be released and we are providing a preview for it, but it's not released yet and it may change before we release it. So it is, you can try out new things, we can get feedback on it, but we are not guaranteeing that the things you try will be released exactly as you tried. We can make changes that will I.

A

Guess the only argument for multiple would be if you're, using experimental for like a safe platform, API point for right, like as we're pulling that speck together right and that change I mean it probably won't, but potentially it could change right as we add stuff in and then, if he wanted another one that was like testing out breaking changes from like the RFC's that Stephens pulling together of like stuff. We want to play or test with that is like a breaking change right to me. That's like a very different version than 0.4.

B

D

Always maybe experimental makes more sense as the next major the experimental is a1 or a2 right. It's never gonna we're not gonna. Do it experiments, although for I, think.

A

Stephens saying we're over time, you.

C

Can keep talking go onto it? I got a drop, sorry yeah. We.

D

Can come back this, but everyone take a look and there's some comments.