Cloud Native Buildpacks Working Group, 25 Jun 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Working Group: 2020-06-25

Description

* Read/Write Platform Volume Mount: https://github.com/buildpacks/rfcs/pull/85
* Inline Buildpacks: https://github.com/buildpacks/rfcs/pull/86

A

B

Hey how's, it go.

C

Pretty good, pretty good.

B

Say I see, exam will survive me disconnecting VPN. So my disconnect yeah.

C

I wasn't sure if the bars cuz, they went red I, don't know. If that was you or me.

B

C

Yep did not survive.

D

Shree get started.

E

D

Joe's early.

D

There's stuff like three more minutes to be late: I.

F

Can leave if you want me to just.

A

Come back in two minutes.

D

Don't forget to sign in'.

D

Looks like the only thing we have on the agenda right now is the rewrite volume, a thing I assume you put that on there Javier I.

C

Did and I know that Ben isn't here, but I'm wondering if it's still worth having a discussion, err around it to at least solidify some of my thoughts, I think.

D

So I mean we can always go back to bend with a conclusion to kind of the discussion right. Yep.

C

Cool I do I'm gonna get started on that yeah.

A

D

Do it, unless you think you want Steven here for the second half no.

C

Again because I haven't really liked concretely said like this is the real thing I am proposing I'd like to just maybe have a conversation, so.

D

Take it away all.

C

Right share my screen.

C

So after reviewing it yesterday, I kind of see where a lot of the other conversations were coming from and I made a reply in the issue about some of the things that I was essentially gathering from the conversations and as I did, that right, I kind of like stepped back and I just wanted to make sure that we were trying to solve the right thing, whereas it seems like there were a lot of conversations that were looking at other benefits to the proposed solution.

C

Where, in my mind, the proposed solution was, you know, anti spec and it was just like hey: go crazy, do whatever you want and then we're like. Oh yeah and it'll help us. You know solve these other problems right, but then they don't also have you know some repercussions that we talked about specifically the linux issues with permissions. So after kind of looking at all that I wanted, I like clarify the motivation for this, at least from my perspective, and what I've seen people request.

C

Is they want something that just works right and if we tell them like hey, this will work for you, but it's really like a Swiss Army knife, and you just need to figure out exactly how to get your stuff in there to make it work right like configure properly. You know specific per builder or per build pack, then it seems a little bit awkward and weird to use right.

C

So, with that in mind, like I, put all my feedback on here right, like what my understanding was, what I was thinking about very specific things like UX limitations and the motivations and overall I started working on something which is very like limited right. It's focused in that primary motivation of hey I just want this when I run it the second time around to have that persistent information of the stuff that it downloaded for another image.

C

If that makes sense- and you know one of the things that we talked about and was mentioned- is that the home directory is already a writable directory, and so it's part of the spec to essentially already have that and in I think I talked to Emily a little bit about it right to see.

C

If there was you know anything major that would prevent this from working, and although there are things again that we kind of lose, because this is very constrained to a very specific use case, I feel like it's, maybe a better approach to the UX of this. You know I, guess request. So the idea our goal here would be that the home directory will automatically get persisted into a volume from packs perspective right and then shared based on the image.

C

The Builder image that's used, so that way, at least from there's, no real, or at least there's a little bit of a safer confines as to not contaminating you know the home directory for another builder, so at least kind of having some separation there and then adding a mechanism so like. Let's go through the first scenario: right stuff, just works, you'd run your application, it just works.

C

You run it with a different image that just happens to be like a java application as well, and you will get a lot of the same caching that was used there right so stuff just works and that's what I really wanted to kind of propose. The second one is like the second request is to like take the stuff that you've already done locally, maybe like the m2 cache and put that into this home directory, and so that's something that you could share to now.

C

The build process, and that's where this home volume right, because right now we have a volume flag, that's really specific to platform, and so I would think that we would want to separate those- and this is like my first- you know kind of idea thrown on the wall here as to what we can do, I'm sure, there's better options. Some of the concerns I have are still about. You know whether or not this is safe to do by default. Essentially,.

B

I, like it I think, I mean. Obviously the maned attraction will be the initial cash stuff. I think, because I think in one of Ben's comments he had like six gig of something right and copying that into a volume, it's not going to be a super fast operation and it won't always be in sync, with your local cash but I, don't know I like this approach of standardizing on the on the volumes that pack sort of already does today.

E

I'm a little bit worried like. Are we talking about doing the entire home derp as a single volume? Because there are thinking about cases like when there is no m2 in home on a bill? What a normal good pack will do is create a symlink from home m2 to a cash player.

E

So then, the things that end up in this home volume might be not helpful or actively break other bills. That would use it naively I wonder if what we want is specific things under home.

C

So I guess: how would you know that from maybe a users standpoint, or even from pack standpoint right like how do you know what the build pack is going to do, whether it'll make it invalid or not I.

E

Think you don't which I'm worried about mounting the whole home directory.

E

Because if home isn't a bind mound right, creating a sibling to a cache player, the thing gets restored is the right thing to do and it's the thing that would happen in most cases or in other platforms.

D

Certificates shared just specific directories from home with that massage your concerns Emily.

E

Yeah I think it would because then you're explicitly saying this exists rather than having the whole home der I. Think we can trust built packs to be do the right thing when stuff exists or do the expedient thing. It's.

D

Like a merger of bends like anywhere proposal, but just for the home directory, am I understanding that correctly yeah.

C

So could you elaborate on that cuz I feel, like you know, we're saying, share certain directories who's, the one: that's specifying what directories are being shared or you know persisted I've.

D

Some it's the end user because it's like an advanced feature of like I, know: I use Sade you like potato bill packs for JAMA and I know that they use like an m2 cache, potentially or maybe that's documented vibe, but kind of full packs right and then, when I do pack Bill Buckley I can use your dash dash home volume thing to say: I want to mount my local m2 into maybe this directory into the home directory.

D

So, instead of being able to volume mount anywhere, I can only find a man tree right in dollar, home yeah, I.

E

Think we would never want to do this by default. I think should always be an opt-in.

C

Yeah I'm trying to think through it because I. That seems to me again like the second.

C

The second motivation right like where I'm trying to share the stuff that I either either have- or maybe it's not right like, but it's maybe not as user friendly still because you have to have that intimate knowledge. And so maybe the parts that I'm really questioning is. How does the end user know what things need to be shared right and maybe that's a part where we could simplify or make it more pronounced.

C

Like ferns just kind of spitballing, but if the build pack were to somehow be able to tell me hey yes, you're able to cash this, you know across multiple builds. Then we could do that programmatically from the platform's perspective from pack right or these are options you know. Even that will help us tell the user hey. You have these options of persisting this information, but without having to dig into the code of the build pack and getting a lot more intimate knowledge into other build pack works from an end user.

C

I feel like that's a little bit more difficult.

D

Are you proposing them like a bill pack authored would be able to provide information of what things you can mount in them. That pack or some platform in theory could leverage if they want to support it. I.

C

Think that'd be helpful. I want to hear if there's any counter to that idea like would that be a terrible choice for bill packs to have to provide.

D

Yeah I mean I, don't think it's terrible I, don't know exactly where we would fit that in the current set of constructs like like. Would you put that in don't pack Tom all the thing statically you know ahead of time? Is it dependent on maybe the build of like what you're doing in your app I guess that potentially makes it harder.

C

Yeah, so we already have this caching mechanism right when we do a build plan that says hey these layers are things that should be cached and you should be able to bring them back. I wonder if we're. What we really need is some way to say you know these things are, you know cached and you could share them, but you could share them across multiple builds, and it's not specific to this. You know application.

D

In that case, would that be like if I want to volume out a thing I just set first narrative to at least of like providing initial cash like when I provide? Basically the thing that's and like / layer, /, buildpack /, like m2, or something.

C

Yeah this is where I feel, like maybe I lose a little bit of momentum, because I don't know exactly what every build Pak does. It sounds like the potato. Build packs, do something specific for the home directory, and so when we talk about the home directory, that's from unfamiliar with that. But then, when we talk about the build packs layers directories and then how those are then associated- and you know linked essentially to the home directory- that's where it becomes maybe a little bit more specific to the implementation of the build packs themselves. I.

E

Feel like having some way to use flares, reuse it cash between builds, where the image has a different name, is a problem which is solved but I'm not sure if it's the same problem that this volume mounting is solving, because cached layers are a very particular concept to the lifecycle where they get restored to specific places and layer Tamil and they have metadata and they get added to the image when you're mounting something into home. You're. Actually.

E

Short-Circuiting that whole process, like you're, not getting a cache flare with your M 2 cache in it, because the built pack will see this thing and just use it. Not every bill pack might do that. Some build packs might continue to make a cache layer and point whatever tool they're using at the cache layer and just ignore what you mounted in the home. But this is sort of like it's a different concept and all a safe one, but a convenient one. Yeah.

B

Less safe and convenient I think that's pretty much. The whole feature here right because yeah I, like it I like the simplicity of this, because it just sort of works and like for most people. This will be a big improvement between builds I would think. But it's just yeah I, don't know whether it's gonna work out so.

C

Which one are we talking about? Are we talking about the current RFC, the.

B

One you've got in front okay, yeah.

C

I don't know if Emily are you talking about the current RC or this one? The alternative.

E

Unrepented your comment about cash players. I think this feature isn't about cash players. This is about icing.

A

E

Cuz, these aren't what layer's and the strict CMB sense you're, actually getting fewer layers when you do this does.

D

Does the potato bill pack that does Maybin stuff, not copy them to stuff into a cash layer? Yes,.

E

So it looks in your what it would do by default is, if there's no m2 in your home directory, it will create a symlink from home m2 to the cash layer and then you'll end up with a cash layer that has your m2 cash in it, but before it does that it checks whether m2 exists and if it does exist, it won't make that cash player. When.

D

In what world does them to exist on it clean build? If you don't have something it.

E

Doesn't right now so.

D

Like this, this check exists for a feature that Ben's proposing basically I.

E

Think it exists to begin with just to be safe, just defensive programming, but it would happen to work nicely if we allow this to happen like this existed in the Java build pack before we.

D

A

D

It's coming over from Mike see the v2 build next as a I guess.

E

A

E

Think Joe mentioned that the Heroku travel pack does the same thing in one of these meanings. No.

F

I mean, like the caching part, yes, but the check for you'd already being there. It does not so.

E

Would it would it like blow up if it was already there? What would it do it it delete it.

D

That's what we do in Ruby land. We delete it I'm, not sure.

F

B

D

E

Seems like an argument against the host by mount, because then, all of a sudden you've deleted your entire I mean to cache for no reason right. Yes, that's.

C

What I'm concerned about this whole thing you know being open-ended like that me.

D

Next I think the difference, though, is like in Java when, like John you're, not doing like Jay and I stuff or whatever right so like, if your copy, no modules, like you for sure, an extension for what 90% of the apps or something that at least build on Heroku and like you, just can't trust that, like like note NPM, will just be like well, this thing exists so like I'm, not gonna, install it, and then you boot the app, and it fails so like it's kind of like the other side of defensive programming.

D

It's like well I can't trust this previous directory unless, like I person, the one who like save the cache and restored it like, who knows what the user put there so like it is safer, 100 percent of time to just like rebuild it right. What.

B

I liked about in one of the comments Ritz like sort of having this be an explicit thing where you're like yeah cache volume, and you specify cache volume and it's empty by default, you can load it up if you really want that could be part of some workflow. Obviously you know it's. You know it's just very explicit, which means you don't run into accidental demolition. So if your local workstation or that's.

E

What I was originally a lobbying hard for, but it been and Stephen convinced me to change my tune on that one. You.

D

Need to hold your ground better Emily I think that's the moral that story well,.

E

I can see either one working in different situations for like I'm, not I'm generally, like I.

E

Am okay with this new proposal? I was also okay, with the more explicit one I could see. The arguments for walls is the middle ground like bill paxton you what pads you can mount into that they will behave correctly for and then we don't have to scope it to home or platform or anything. It's just the set of things that you're allowed to do. I.

D

Mean I guess like you're talking about how the sharing layers across mold builds is maybe a separate concern, but like I, wonder like this home thing like on one side, probably many bill tools, probably by default leverage dollar home for putting stuff in so like you can get. There's like an argument made of like the 80% or whatever, but I think, like all that functionality, probably in bill packs a day like if you're doing it like what you said.

D

They're gonna be empty right now and so bill packs that are being built probably already or having to work around. The fact that this thing is either empty or I, can't trust it, and so you're, probably gonna, be leveraging a layer cache for build anyways of some sort, whether you have volume mounting or not, and if you're able to just share the layered volume does that a cross build?

D

Does that solve them like the cache volumes that solve the problem, because it seems like that's the main use cases to share a build cache layer like not necessarily but I, don't cache and most the time build packs are gonna. Put that in there yeah.

C

I think the part that we're missing, though, is whether or not we could then share this layer across multiple applications or if this is specific to this application right I think that differentiator is necessary for different programming languages like em. We don't care. You could share this across any application, but node modules. That would be specific to and ambition if I'm not mistaken,.

D

And two is different than node modules. Right, like m2, is just isn't emptied just like the download of the cash from the maven central registry, yep yeah, there's an equivalent and note as well. There's like a 10:00 p.m. something at all that anyways there's like a fan named Jim as well. Wear it like catches. The contents and you know crates IO has a thing. Rubygems also has a thing like it's a pretty common practice.

D

The actual unpacked of no modules is I, guess a thing that is definite, but you could also make an argument that, like, if you have a thing like there's, probably some like we done and gotten this ask of like certain types of apps like you're building 10 things of like basic the same stuff dependencies. You just want to share it across all those apps or something yeah.

A

Sorry gone, there's.

E

No way to distinguish between those two types of caches that we have cached route falls like once. You talk about this being a cached layer that we do use some generic mechanism before I think it gets really tricky and also according to the spec.

E

You know the restorer is going to copy a cache player into the layer, stir like if you had a giant empty cache that had every dependency from every app you built I, don't know if you'd want to sit around and wait for us to copy that across a file system for every building.

C

So I think we want that, like the platform is the one that provides that or yeah that information or data to the restore phase right.

C

So it would be up to pack, for instance, where it gets that information from.

E

Which information the.

C

The cached layers right, so we, if you know kind of going back to if you had something like a flag that says you know, don't use cash or don't use I guess what should we this cross app cache right? Then they wouldn't provide that cache. Those types of cache layers back into the build process, and so then you don't care you've optimized, that the platform layer for the stuff that the restorer will do I.

E

Don't totally follow, like I, think we'd have to sketch out something different here for me to totally understand because I intuitively, if we could do something with cache layers, would be cool I, just think it's complicated and I can't imagine a good way to do it without thinking harder run. It.

C

Yeah, um for the sake of not being completely silent here, I think the direction is still something that we're I guess. Maybe I want to gauge that right. Like do. We think that we should lean more in this direction, which we should be looking at things that the build parks themselves could provide. Even though granted it could be complex, it might not work at all right or do we do what the current RFC says.

C

You know we should do, which is basically open up the floodgates so that anybody could do anything and essentially shoot themselves which honestly I'm kind of against so I'm, not sure I would like check the box right myself, but if that's what everybody else decides, we should do then, obviously we'll get it done. I.

D

Guess I'm the only person on the core team, whatever that did, though, yes, so I think the floodgates by default like I'm, not gonna block it, but it does make me a little uncomfortable for reasons that you said hum yeah. It's definitely just like the it's like. We did not come up with the better hammer, so we're giving you the like the hammer that does everything seems to be like what the solution is.

B

Or if there's some way to make this from the back side a bit more interactive, where you know, let's take the into example to Java build pack sees that there's no m2, and then it does whatever the right thing is right: it populates the m2 I, don't know what I don't know enough about exactly how that works, but then on a subsequent pack build it could check. You know if there's no I think you can. Can you a lease the same volume multiple times anyway?

B

I was thinking that there's a potential when you do a pack build on like your next app it could it could almost interactively you know. Unless no cache is specified or clear cache, then it could. You could see that there's already a volume out there from a build pack.

B

If the bill pack could say that I potentially populate this m2 directory in like development or whatever, then then, maybe we can go at it that way and on subsequent builds- and you know it would be part of the build plan, I guess and then it would anyway I'm. Just wonder if there's some communication that we could do where you be able to enter to be like hey, there's already m2 cash, would you like to default pack to, like you know, mounting this by default for subsequent builds that require I, see.

C

Something completely different, essentially, that is more yeah.

B

C

To where essentially yeah yeah.

F

And never that not even not doing anything with the local and to write like you're, just saying the first bill that it populates the cash yeah as normal right yeah.

B

I think so, and I think I mean I. Think there's when you're talking about docker volumes. There's always the sort of you know escape hatch of it is a docker volume. You could do whatever you want with it once it's created right or if you knew that or if it was like a common path of gonna, be pack, you know builder name, then you can always just kind of pre populate it yourself. If you really want to.

C

So if I'm understanding, it correctly is a proposal that, instead of what is currently in the RFC right, we add some logic to Park. That looks for very specific, well known locations that we know are safe to cache right and more or less do that ourselves. Instead of relying on the build packs to give us that information as a first pass, because.

B

With those known locations being part of like packs, config or something like that right and we just dump some default like into, would be the first right and then eventually, if other languages do it, then you sort of have a you know. You have the configuration at the pack level to add more directories that are safe to kind of Auto check for without the build packs having to know about and build packs can just I, don't know. It still feels a little weird.

B

The pill pack side, because there's nothing that sort of tells you that you could do this. It.

D

Feels weird to do this on the back side too, though, because that's like super bill pack specific right, like dot m2, is very much a like. Why should pack know about m2 at all like it should be language agnostic, like I know it comes back to even like when we talked about some of the Ben develop stuff right.

D

It's just like do you like it feels weird to hard-code like are syncing like no modules or those things back and forth, or excluding those things like, like the platform of tools, should be pretty agnostic to not have to know about that. I mean I. Guess like you could make a case for, like you, just have a set of defaults that is in a config file that a user can edit or something, but that does.

B

Vary for this on the Builder, the Builder level like when the builders put together with all the build packs. You know, could you add some labels potentially to help to help this out? So it's not PAC specific, but it's builder specific.

B

So at least the paths can come from bill packs that are there. When you put this thing together, I feel.

E

Like if whether the pads are safe or not depends on the specific build packs, I wouldn't want to move the encoding of what those pets are further away from the bill. Packs.

C

Yeah I mean to me that seems like the right thing to do right and again. I feel like that would solve the primary motivation right. I, keep kind of going back to that, like that's really what I personally care about and I know that that's very different than what's in the RFC right now, right and I guess maybe I just want to kind of hone in and go back and say, like you know, is there backing to? Essentially he step back right and and go a different direction. I mean.

D

I think there definitely is that's kind of the point of the final comment period for one and like Falcon parent is not like. Please be silent, don't say anything it's like if you have a problem. Please raise two concerns before it closes right.

E

D

You know if it was like I think that's true right, like yeah, there is a better idea and it changes how we think about it. Then we should definitely not like Nestle filibuster but like exploring earnest, it's like a valid concern or alternate direction. In my opinion,.

B

Potentially I feel like we're. It's a build pack solution mean that one job a build pack would not be compatible with another chotto pack. Potentially I mean it's, probably okay, if it's not originally but I, don't know it's. It's kind of goes back to provide requires with the sort of loose naming like you know. huh How do you make this either safe for all Java, build packs to sort of do, or maybe you just don't well.

D

It's probably someone self-contained, though right in that sense of like if, for instance, a you write, a Java, build path that does not leverage and this stuff right.

D

You kind of don't care if another Java bill pack happens to have an two thing that shared and you both could get pulled in to be part of, say, like a spring boot bill pack later down the line or something right like at the end of day, as long as like the pen, C's get installed and unpacked in the way that that other bill pack wants, like it, kinda, doesn't matter how the cash gets restored or generated as long as your bill pack functions and outputs the right things right.

B

Yeah I think probably I think there's still some room there for like one built pack doing something weird to them to like I know it's like they know it's persistent and start abusing it in some weird way and then, like you know, I know that, like messes up another build pack that was just using it for peer into a.

E

There's a spectrum of like safe on one end and allows you to do many things. That could be useful, and maybe we can't predict what they are upfront on the other and.

E

We take the existing proposal and just dial it a little bit more in the safe direction like what, if we just didn't support, buying mounts had to be volume mounts, but we helped people copy their local things into volumes to make it easy stuff like that, then we get away from the OS problems and it's not as convenient, but it's a bit safer because you're not going to accidentally destroy your host machine and then I would say that that's a thing we should do for directories or normal files.

E

I do think we should have binding mounting of sockets, though.

B

D

That just a setter footballs wow that feels separate. If you go down the volume now direction, yeah.

C

D

C

My comment was that I feel like sockets just kind of interweave themselves into this conversation versus we really thought about sockets, specifically.

E

I think we should support by mounting of sockets, even if we don't support by mounting anything else. Yeah.

D

I think sockets came in mostly because, if we're gonna do bad mounting for this other use case, it makes sense. You also talked about by mounting for sockets in kind of one day. Oh.

C

Yeah I wouldn't be opposed and I think that's where maybe I was going with the you know. Do we really want to deviate completely into something? That's maybe more topic specific or just you know, tighten some of the concerns in the current RFC.

C

My initial proposal was just limiting it to the home directory right, where you have the platform directory and the home directory, both of which are more or less safe right in some regard, given that this is somewhat unsafe, which is kind of weird, but you know that at least would make it or yeah it would make me feel a little bit more comfortable than saying you could just mount anything anywhere. I know.

D

The idea Emily had was the thing that was brought up before right, like when the proposal was originally came around for discussion. Do you know why that was shot down Emily.

A

E

Don't think it was shot down. I think that's always been a valid option. Right people can copy into a volume I think it was originally proposed, as a workflow people might want to use instead of using vine mounting I, don't know if we talked about completely locking it down to only supporting that workflow.

D

It's the concern, in fact, having two volume: that's expensive,.

D

Or whatever there was like that I thought, there's an example or something like there was like a many gig like cash right and that pain. That costs is like still pretty expensive. Yeah.

E

It's painful right, it's not as fast and it's not as easy I didn't.

B

Say for today yeah like, if you keep going between docker and not docker, then this will never be comfortable. I.

C

Do wonder if that's more or less a concern for the bin develop floo than it is for this workflow all right like a build workflow, even a local machine, maybe shouldn't care about your local cash or your local files, and it's they've been developed where you really want that fast iteration and that's where a lot of that tweaking could come in yeah.

B

I think so too I think been developed if it had been here. We probably wouldn't be talking about anything except for sockets during build because I think if you had like a developed cache like a develop him to cache, then like seating, it I, don't know it seems like you wouldn't want to reseed it often from like your non pack related builds.

B

It kind of feels like if yeah, if it was like a pack, develop machine worth of home directory kind of like the proposal here it's and they would mostly work and then, as soon as you do pack build, it would not use those directories to produce your clean because.

E

I would need to see it up a concrete proposal for been develop in order to agree with all that, like I, don't know what been developed does and until I know what it does it can can imagine it solves any problem that is tangentially related to development. Yes, that's true.

C

The scope of it, like the purpose of develop, is to focus on the development workflow, whatever that is right, I feel, like that's the scope.

E

Proposal is that it starts a development server instead of producing an image, but we.

C

E

Make building images more often than I'm want to start a development server and I still want that to be fast, like it's, not I, don't I hate waiting for Raven to download for ten minutes. You know I, think.

D

The important point, though, from maybe that discussion around been developed, is mostly I think the proposal. Would the problem statement probably would change in the sense that, like there was, the type of that was just brought up of white? Do you care, if, like you're using the local m2, cash versus I just want to proceed its cash and then, if that deviates from what I'm doing locally, that probably doesn't matter right, like I, just care to make the build fast and not necessarily that I keep that thing and saying or something.

E

E

Guess the reason the syncing matters to me is because I've almost always already downloaded the dependencies onto my host machine right, so I either have to pay to copy them on to up volume.

E

Or I have to pay the cost of downloading them again in pack and right now, if I build the same image multiple times like I, do get my empty cache back, it's a cache layer. It's not like! We download it literally every time, it's just that it's done using the cache layer mechanisms, so the cache is populated with things specific to that image. So.

D

If there's a world where you could proceed, the volume pay like a one-time toss, but then you could share that cache across multiple app builds.

D

Does that solve your problem and the hot white happy future world where you solve that problem.

E

It does, to a certain extent, yeah I.

D

Mean it still probably sucks that, like what you're saying like you have to precede it, but hopefully it's like a one-time cost across many apps versus a one-time cost per app, which I can see that thing very annoying, especially if you're doing a lot of demo apps or something right, you're just pulling lives all.

E

Right clean my daugher volumes and I forgot to label it. I have to do it again, but yeah.

D

Yeah I guess the I, just like the distinction between actually caring about keeping like the m2 or I guess in that account to example, like the cash in sync, between local and in like pack, world versus or the platform world versus, like you really just want to provide initial cash to make that fast, right, I think the sinking doesn't actually matter you just care about the performance.

D

Is that true Alan, for you.

E

Well, I don't know if I'd then go to build different app. I have to sync it again right if I were to you know, I'm, always compiling that locally. First, before I can pilot impact. So every time there's a new me, so dependencies I need to download I. Have this problem again like have to download its license it once, but it's simply an improvement.

E

They've retainment, my particular use case the by mounting m2, is clearly the fastest best thing, but my particular these cases, not everything and I, understand the arguments for why enabling that is, has grabbed ax right.

D

Yeah I guess like more than just like the concrete implementation I most just want to drive back to like the problems, we're trying to solve.

D

I. Think that's like one of the things hugger was trying to kind of get back to right, like whether it's like buying my amount or copied volumes like like the problem that we want to solve is mostly we want. It's like for performance right.

E

Yes, if we're talking about the performance problem, there's also a socket problem, but that one can be mostly solved with the existing platform mounts. It doesn't feel as pressing.

D

So syncing is not a problem. We're trying to solve that just happens to get us performance the best way, I think it's the mostly the point. I was trying to make.

B

I wonder if Mac could pull that cash from like a like known, docker images like if you stuffed all your m2 cash into like a layer like you know, pack create cash image for him to and then pack could start looking for that, like as an additional like you know, additional cash, it image to look for potentially a that layer and kind of I, don't know I guess I would have to enter all put it in the image for the build. So I'm, not sure that speeds things up, demon.

E

Images are also like really slow to put things in and get things out of, like we were doing it didn't even allow demon images for the caching we have now like we started out allowing in it was performance, was so abysmal that we just turned it off so that no one would do it.

D

I just thought the side of packed are there other platforms that would leverage some of the stuff?

D

That's really own time out. Local builds but build.

B

Kits, probably the closest analog to what we have now I think layer that we're talking about we're like now. They have like a way to you, know, reuse, some things from build to build I.

E

Feel, like most other platforms, wouldn't want to do this.

D

Yes, I'm, just wondering like you been for like it, makes me think like the kind of Sharon cash is cash vein, tween apps is actually pretty important, like even I. Imagine like KPAC would leverage something like that for em to catch right, maybe for an organization, maybe essays across lots of organizations, but within your own organization like not having to pay that cost.

C

Yeah I'm looking at Matt to see if he responds to that.

A

You're, muted, double muted, be honest, I'm kind of half paying attention, but um it's not something at least I've put a lot of fun to I, guess, theoretically, it could be possible to share across an org.

A

It certainly seems like it start with the packbow case.

D

Is that something cake users actually want, though,.

A

We're not as mature as like PAC users. It's in a sense. Perhaps we don't have as much feedback but so far I. Don't think! That's all we've come across this jacket. We think I.

C

Do wonder if it's like a fire-and-forget, so they don't really care too much about the performance implications or micro optimizations, but if you're running locally, you probably are a lot more aware of it. Yes,.

A

E

Like sharing a single empty cache across a bunch of builds, they get far fewer copies of large dependencies like spring boot and stuff like that right. So.

C

If that's even viable, right, I feel like the right direction would be to maybe push it down into the build packs to let us know the difference between you know, app, cache and I. Don't know builder cache, Oh.

B

C

I mean I could definitely work out more details based on the feedback, I'll kind of do both I'll kind of do the proposal to just heighten some of the you know concerns with volume. Caching, and then you know the kind of like rehaul kind of rethinking all together and I'll reply to that thread.

A

D

Sounds good thanks. I'm here, I've mapped into rehaul is a lot more work. I'd.

C

Actually, even do it as an RFC, you know altogether, so that we could have just a specific conversation around that.

D

Yeah I mean I think another useful thing that Jessi come into is like experimental flying's like I. Almost wonder like. Is it worth having a set of things that we want to trial out that maybe we're less sure that we're not promising won't be there forever.

C

Yeah I mean I would say that if we take in the RFC the way it is right now like, we should definitely better be behind experimental and then kind of see how many people shoot themselves before we say like I yeah baby, we should rethink this.

E

Can be nice to sort of make that a feature packing thing like you could turn on or off experimental mode, and if you try to use an experimental feature, when you haven't explicitly turned it on it, just tells you you have to turn it on.

C

Global I would hate to do it like feature flag based.

A

C

We already have the global concept, so yeah.

C

Yeah I mean from an implementation standpoint right. It's super easy for us to do so. Maybe this RFC is good enough to get in right now. Put it behind experimental, see what happens and then still keep thinking through more. You know, specific implementation that can be used outside of just pack right thinking about K pack and other platforms as well. That could leverage this.

D

Yeah I mean I even imagine on Heroku like people that they ask the ability to not pay the cost of downloading stuff again so yeah.

A

B

Be a big leg up for even like Salesforce functions, right like we're, talking, tiny little functions and like constantly have to download you know hundreds of megabytes of NPM every time they create a new function, even though we they clearly already have all those dependencies locally.

A

D

So we have four minutes left I, assume that's not enough time or if for Joe's inline bill PACs version thing for me: uh yeah.

F

There's not much to talk about here. Emily and I were talking about the inline. Both a car FC in the version field and I think we agreed that in the same way, that version and UI URI are mutually exclusive in line and version should be mutually exclusive, at least for now we can have the we can have the registry conversation later, but I think Emily brought up.

F

Some concerns I think word about why that might not be a good idea, but this doesn't also like I think even in the future, I think we would probably use the project version if we wanted to do that, but in any case, I think what we agreed on was that it should probably be the yet in line and version are mutually exclusive in the same way as URI inversion and then I'd like to see us warned. You know.

F

If you have ID version, URI and inline in the same file, we either need to set an order of precedence and warn or generate an error I'm a little bit worried about the error condition because I don't want people to get into configuration. Hell we're like the copy-paste and ID version and then I add an inline and that breaks, and then they remove all three and it breaks again, and you know what I mean like nobody is I'm like nobody's gonna know it like inherently like or like I'll priori.

F

What the right combination of these fields is so I want to think through that a bit I'll probably update the RFC, the.

D

The project version thing is actually pretty interesting as an idea as well yeah.

F

I think it makes more sense because, like when we're talking about it, you I mean you really want to tie it to the code base as a whole. I think so it doesn't make sense yeah to use something like that. Instead, but we I mean and there's other questions to answer about.

F

If we were to go into a registry like what, if you have multiple inline, build packs and yada yada yada, so I don't want to.

A

Tackle that yet I just.

F

Want to leave the door open too.

C

Yeah and just a little bit of insight, I think we've shipped the directions on a lot of the pack implementation to be a little bit more strict about the Tamil fowl configurations so where we would error. If there's like a field, an unknown field or something like that and I, think that overall, it was with the intention of helping the user out as well, so that there isn't a field that they. You know for the example of, if they misspelled something right and then just it's warning. Instead of throwing blowing up.

F

Yeah that makes sense.

E

The last thing I was wondering about in line build packs. Just before this meeting is do we need to have an API key for pill pack, API, probably rent.

A

C

If it's just in line I'm wondering what does it get it.

E

Gets positional arguments that might change the environment variables someday they'll format, it writes things in the later surgery can be interpreted differently.

F

What would be the default? I thinking it like I'd hate, for it to be required.

D

E

Thing right now, the default.

F

E

Oh one, if you don't set it because.

F

E

Introduced it, we had to do that right, yeah.

F

No, no I mean it like as a bill. Pak Tamil, that's fine! It's just for the inline. It's like defaulting cuz,.

A

You're a long socks that green.

F

Maybe it's like: could we look at the other, build packs and use like the men version or something like that is the default like I'm like if you only use 0-3, it's just 0-3, if you 0 3 and 0 2, it's or whatever, it's goes to 0-2.

D

Okay, we could change the default when one out comes around right to be one Oh.

E

Yeah, we could also just have a lifecycle, have a concept of defaults now that it has multiple values for these things room, and we could, you know, lifecycle at least, decide whether we're changing a default or not.

E

But yeah your pipe might run differently, made different life cycles as the defaults change, yeah.

F

But yeah I think you definitely need an explicit option for that and then we'll have to yeah. There's I think there's no way to avoid a little bit of config hell like there's gonna, be an API, but that's mutually definitely matrix good with like URI inversion.

D

Yeah I'm, probably like I, don't like including it like you're saying Joe but I- think it's pretty common in like survey or Travis to like be like yep I'm on this version and yeah. Maybe.

E

Just require it cuz, it might cause less problems. Then, having the defaults change.

F

Potentially, you think require it and then potentially make it optional after one, oh and default with the one. Oh.

E

F

Just be nice, yeah just be nice to think that, like that would be temporary yeah.

E

I, don't think like that'd, be so beautiful there, but I yeah.

F

Like I really would settle on anything, I'd want to put it into an example, see what it looks like. Sometimes you do that and it's like man, it's not too bad. Cuz like it seems like. Oh that's, gonna, be so long, but I think most people won't specify a shell and we'll just use the default. So and then you don't have version anymore. So it's just ID API in line it's not a.

C

Really terrible idea but I'm thinking of, like you know, markdown, where you could specify the language at the top, like you get specify the version at the top, but I think it's a terrible idea. Just that I throw it out, I mean.

F

I definitely can't imagine why you'd want a different API version for multiple in line build packs and the same project. Tamil, oh you mean. Oh, you mean in the inline script. Is that what you were thinking? Yeah.

C

Again terribly.

F

That is durable.

D

Can you even cut ID if you only have one inline bill pack and interests, it's auto-generated for you, based on your project, yeah.

F

I thought about that, um but I kind of want it being a bad idea. I just feel like what do you put there I mean I. Guess you put in line but I'm Lois talking about putting in line for the version I think.

D

There's a little blanket worth.

F

Project name right: oh okay, maybe I.

D

Mean I'm just riffing on your project version idea: yeah.

F

I'll think about that too, because everybody.

D

Like API version, I feel like API versions, probably more important than the idea.

F

Right, I, yeah, no I, think I was fine with ID, because there really wasn't much else that we were putting in there, but yeah for certainly had some other things. That really are essential. It'd be nice to you already have a project ID yeah.

D

I also think that and I'm more convinced on the inline table now to of just like you just have a bill. Paxton line and the only thing in there is like the script for probably most people, and so you don't have to like. Basically, all the other stuff is optional.

F

Yeah I'll still look at that. I just want to see it.

E

Confused by that comment, he.

F

Chanted he had the wrong thing in there. Yeah.

E

D

Basically, just like making in line an actual table versus just like it's like, instead of like adding more keys into Bill packs, make it a table that has the inline specific stuff in its own table in DotA and.

C

Then, inside that, in line you would have script, shell and version or API right, yeah.

D

Exactly like, whatever we want to add to kind of keep it separate from the normal Bill packs, you know yeah.

C

I definitely like that, instead of like the exclusivity of different values, I think it's a lot easier to comprehend as well.

E

Maybe I'm still like worse at Tamil, that I should be after this lion. We're getting this project I hate.

C

E

C

I'm Stewie this.

E

Looks like it's like an array of in lines inside a bill pack yeah.

C

I might be doing it wrong, but you know what I'm trying to get it right. It's like a Bill pack in line property, yes or object.

B

With this work order like if you had like free bill, packs I'm in line three more bill packs and another in line what they all roll up, as you would expect.

A

D

I believe so anyways. We are six minutes over. So.

A

You know Ernie, oh yeah,.

F

I feel like I've enough time line.

A

Thanks everyone.