 There we go. Hello and welcome to this month's community office hours for the package team. The goal of these meetings are to kind of have an informal chat with members of the community for any ideas that they would like to contribute to GitLab or any questions they have in terms of how to implement them as well as just give a general chance to ask any questions that may come up. So we try to do these about once a month. And this month, we have a few people attending. I guess I should turn it over and say, are there any open questions that people may have? And I see we have Ethan here as a regular contributor. So currently with the Go MVC, I think it's pretty much just waiting for a security review. So Steve, all those answers or questions that have been answered, documentation has been taken care of. So I think it's just waiting for the somebody from the security team to see or they requested a path traversal tests. And I wrote a couple of tests. So waiting for them to say whether or not that's what they want. So that's, I think that's just waiting for them. I have nothing else. I think Steve mentioned he was going to join this. Let me reach out to him and see if he's available. So a security review. And has it gone to maintain a review yet? Not quite yet, right? No, I don't think so. So it's security and then maintain a review. I'm really excited to have that feature launched. I'm sure you are as well. Yes. Definitely a MVC kind of thing. There's a number of other pieces that as a Go developer would make it much more useful. But yeah, first steps. And then Ethan, you mentioned you were hoping to talk about the implementation of this issue to add the project details for specific packages. Yes. Yeah. So Nick was working on and I think pretty much finished the UI to show project details and build details if a package was published via the API or via CI job with CI token or CI job token credentials. So you know, they do various ways to identify other links between packages and projects not pushed via CI. And so that's something I'm interested in, something I'm interested in helping with. But there's not really been any consensus on how to do it. And my feelings are that doing it automatically has a lot of potential problems and a lot of potential messy details. And essentially, my suggestion boils down to not having some kind of schema element for here's all of the versions of a package and just handling that kind of conceptual grouping of packages in code as opposed to in the database and then adding a explicit link from a package to a source project and get revision. And so details about how I imagine that working. But essentially, that's the idea is having it. There's a current way to create a link via pushing from CI, add a separate way to create a link, possibly manually, and then automatically group up packages based on version as opposed to explicitly doing that, which I think. I remember seeing an issue that's already talking about doing that in the UI. So this would be more of a back end type thing. I like. OK, so just so I understand, the first step beyond what we've did for when it's built using the job token is having some manually way to enter in a project name. Yes. That probably takes us a pretty decent amount of the way to if people want to enter that in, it would be. Do you think on that note, we don't really have a way for having a readme for packages either? Do you think there's a need for other user-generated content to be associated with a package? I think that could be useful. I haven't thought a lot about that. So I'm hesitant to say much about it. I think that explicit, I think creating an explicit schematic link between a package and the source project would allow for a lot of things like that. But yeah, I haven't really thought about it. OK. Nick, you were going back and we were talking about this a bit in the issue. Does this approach make sense to you to sort of have the manual way? And I guess I didn't understand the implementation of how we would do it programmatically beyond the manual entry. You mean my suggestion? Yeah. So the main thing is adding something like package source, adding a database type. And I haven't looked through this in detail or read through my whole blog post and the issue here. But mostly just creating that schematic element, having a way to create that link and then displaying it for now. There's some things like go that when the package is created, that link could be automatic because it's implicit in the structure of language itself. And there's some things like NPM where I think it would be a good idea to automatically create the link based on metadata if there is sufficient metadata. And then there's other questions like if I have already linked one version of a package to a project, if another version of that package is uploaded, should I automatically recreate that link? But I think that's beyond the first steps. So basic implementation, create the database element and create at least an API for manually creating those links and then hook it into the UI that Nick has made. That does make sense, Nick. Were you going to say something? Yeah, I was just going to say that sounds pretty reasonable, pretty approachable to me. I think creating an API endpoint to link these two, and Steve can correct me if I'm wrong here, probably isn't too difficult. And then wiring it up in the UI is very straightforward. The current UI that I've built that displays the project link right now is basically only pipeline projects. So if a package is built via a pipeline, it will link to the project where that pipeline lives. So we would potentially have to add either additional logic to display this new link. Or I guess it's possible, although extremely unlikely, that you could link a package to a different project and have it built via a pipeline that belonged to an even, like a third project. So you could possibly want to display two links there, but I suspect that that's very unlikely and probably overkill. So you'd probably just want to prioritize it and display. If there's an explicit link, display that one. Otherwise, try and figure out if there's one related to the pipeline. So I was thinking when I was writing this up, I remember thinking if you have A, B, and C, and A is the package, and B is publishing it via building, and C is where you're publishing it too. Then it makes sense to show, so if the user has manually said this package that we've uploaded is linked to the source is this project over here, I think it makes sense to override the pipeline information saying it comes from this project the user has said as opposed to the project that the pipeline ran on. But there's still that display of activity that if I'm correct, Nick, I think the CI shows up under that activity and says this is the history of what's happened. Yeah, it links to the commit that generated the pipeline. So that would potentially go to project C in this case instead of project B, which I don't know if that's so bad, I definitely think that you would want to only display one project. And in most cases, I think you'd probably want to display the source. So if somebody's actually gone out of their way to say this project is the source of this package, I feel that that's probably the most important piece of information to display in the header. But maybe we could do some clever things. In the UI, for example, we could point out that that commit is to a different project, for example, or I just thought of something there. Yeah, so we could probably just do something in the UI, like worst case scenario, saying that this doesn't match the project that's linked above. We would, if in the case that you've linked a project URL and that it was still built via pipeline, I would still think you would want to know that it was built via this pipeline. You'd want to link to that code. I think to Ethan's point, you'd still want to see that activity, right? But probably, I was thinking of that it would basically just be another piece of package information, that if there's a project URL, it would be added to this table and we would still show the activity if it was built via pipeline here. So I was talking about overriding the stuff under the header there. Yes, here. Yeah. So if a, is there a link to the project there? No, it kind of just links, oh yeah, this is the link. Okay, so that's that link there and the branch name was when I was thinking about overriding as opposed to leaving the history, the activity section there. Okay. That could work for me, because there wouldn't be, this would basically, this is the project URL and then yeah, you would want to point to that branch and we wouldn't overwrite this activity, which is actually saying which pipeline triggered it. Yeah. Okay. That makes sense to me. And we were talking about the, I was on mute before that you were talking about the adding versions to a package. So right now, I can share my screen again, actually. Right now we have, I think this project shows it off. Right now, all of these packages are treated as treated as different in total, like all these versions will soon, I think Nick this change is being worked on now, will collapse all of these versions into one package type. So you'll see, or one package name. So we'd click on this and then we would probably, we'll see a versions tab. I think it's either, it's here maybe? Below activity, Nick? No, it's between the title and the package information box. Here. Yeah, yeah. And so the project name will still be, will be inclusive of all versions. I'm assuming, right? There's no problem with that. Okay. So Steve was talking on that issue. Steve was talking about a project entity kind of thing that, or package entity to describe all, you know, that grouping of all of the versions of a given package name. And so essentially my strategy is leave that grouping as a logical thing, as opposed to actually creating a database element for it. Since the grouping of different packages by version, well, there's a lot of detailed reasons I talk about in there, but essentially I think it's more flexible. I think the loss of flexibility is not worth the advantages gained from having an explicit database element for the kind of umbrella package. Yeah, I agree with that. I think like the only reason to really consider that is like if it's a vast improvement on performance or, you know, optimizes something from that aspect, but otherwise if we can keep it separated for that flexibility, that totally makes sense. I don't think I fully understand could you dumb it down for me? Are we saying that the project will be tied to a version and not the parent package? So we won't have a database entry for the parent or will actually be each version will have a database entry. Yeah, so like it is right now, each version has a separate package entity. And I'm just saying, don't create a separate database element that groups them together. Yeah, okay. Let it be handled by the UI or handled by the logic. Does that answer your question? Yeah. So one thing I'm a little bit unsure about if we're gonna do this manual linking and we're gonna build some kind of UI to link a package to a project is like what kind of permissions are gonna be required for the user to be able to do this? So do they have to be a maintainer of both the project that you're linking to and the project that the package resides in? Or do they have to have some other kind of permission models? Like is there a way to unlink, for example? Obviously these are just general questions I'm not expecting like an answer from anyone, but it's probably worth thinking about because I guess it's gonna be very easy to like, if you're given a UI or even API driven method of doing this, then mistakes can be made and all that kind of stuff. So we need to possibly make these reversible or blockable or any other kind of not allowed to do this kind of action. I think definitely they should be removable. As far as permissions, I can see an argument for requiring maintainer on both. I can also see arguments for not. I think some of it comes down to is this going to have an effect on the source project? Because if the link, if we list packages or something like that, then if I was maintaining some package source, I wouldn't want random things showing up that I didn't create. But if there is no impact on the source project, then maybe, maybe not, I don't know. My first, without thinking about it more, my first instinct was developer and above because they're the ones who can publish the packages. So if you can add a package, you should be able to add some metadata about it as well. And then I was thinking, would we want to do any kind of validation of the URL? Like it confirm that it's not malicious or something and that it's actually goes somewhere, that's a valid URL. So you're talking about the package source pointing to an arbitrary URL? Yeah, if someone actually put in something that was malicious, that was like a virus or something like that. That's interesting because I was expecting we would just either put in a GitLab project, alias or ID and not a full URL. So, but that does open up interesting possibilities of just putting any old URL in there. Yeah, like if it's on GitHub, then maybe you still want to create a link. Yeah, so to be clear, I was also thinking like Nick was that it would exclusively be linking to another GitLab project. But that is an interesting idea. Probably makes sense to start with only GitLab projects. Another interesting idea that for maybe this is, this is, could potentially be seen as a drawback. Although I'm not entirely sure how much this scenario would come into play, but imagine it, so I've created Nick's package and if it is using my package in his project and Steve is using my package in his projects, there's two packages. Now, if Ethan goes and links his version of Nick's package to my project, that won't necessarily touch Steve's version of my package in Steve's project. So Steve will have my package, but not linked to the project, whereas Ethan would have my package, but linked to the project. So that kind of flips things around in the sense that this feature really is only going to be used if the developer of a particular project really cares about where the package is coming from. Is that true for people who are developing packages? They probably care about that information though, and they want it to be accurate. And I'm a person, I would guess. I don't think what I said there is a blocker or prevents us from doing any of this. I just think it's an interesting thought that I didn't necessarily consider right at the beginning when I thought this was a really good idea. It looks like Steve, you're about to say something. Well, I was going to check something first, but so in NPM, if I recall correctly, inside of the package JSON file, there's an optional field for the registry, or say for the repository, the Git repository. I'm wondering if most package managers have something like that, that we could extract when the package is uploaded and then link from there. I was going to talk about it as a potential second stage, automatically scrubbing things up like that. Okay, yeah, I think I might have jumped in while that was in the middle of the talk. Okay, yeah, I think that's definitely something to investigate. And go, it's implicit in the package name. Though there's the whole vanity URL thing, so go supports, I can have a package on GitLab and have a custom domain and use the custom domain as the package name and have it set up correctly so that that responds to particular requests that point to GitLab. So it is implicit in, the linkage is implicit in Go, but it would require some extra steps, though it can be explicitly verified. Cool, yeah, I think if we check out, if Maven, Conan, all the other ones have options for that, it would be worth at least finding out. Yeah, I think Maven does, it's been a long time though. So does that sounds like a good idea for me to pursue? I think so, yeah, I like it. And now that Steve's here, Ethan, did you have any questions or anything about the Go proxy MVC? Steve, is there anything I need to be doing? No, I think I have no one holding it up right now with just getting around to testing. What's that? I think we're waiting for security also. Yeah, security reviews in progress and then like my review is pretty much done. I just wanna make sure that once it gets into the maintainer review and whatnot that I've got sort of a set of instructions to add to GitLab somewhere of like, if you're running GDK, here's how you can play with this locally and have it work. And it turns out GDK is very picky about ports that you can use. So setting it up with port 443, which is somewhat needed for doing some of the Go work is a little tricky, but I'm getting close. I'm gonna spend the afternoon on that today. Do you see that proxy thing? What's that? I created a little simple HTTP proxy so that you can run GDK on whatever you want and you know, have a local forwarder that will, so you can run GDK on port 3000 and then have a little proxy that will point to it. Oh, I might have missed that. I'll find that that's in the issue. Somewhere I mean in the MR. Yes, if it's not clear, I'll tag it. Yeah, that would be awesome. I think part of it is also my, I've never really dealt with port forwarding and all of that kind of stuff and setting that up locally. So I might just be having some trouble with that as well, but I'll see if I can figure that out and ask you if I have some questions getting that set up. Cool. I haven't read anything else that we should. No, I think we have another community member on the call. I mean, sorry, I don't know the name. I see SPAGRT wasn't, wasn't sure if you had any questions or anything particular that you want us to talk about during the call. Maybe not, that's fine. Oh, so just type the text just here to listen. No, that's completely fine. I mean, one question that came up to me is we're talking to that contributor about a license. I mean, how much of the work is, I mean, how many of the issues that you typically talk about or office hours are they, do you know what percentage of them are like enterprise edition features or like? Yeah, for now, anything, whenever we're talking about the package registry or the dependency proxy, those are premium features, but we are working on a change now to move the package registry offering to core. And we have an MR open that just kind of simply changes the license files. So anybody who has a self-managed instance will be able to use it in the core or starter. And then over the next several milestones we'll actually plan the migration of all the files to move it properly. So I think right now it's probably the majority of the contributions we're seeing are enterprise edition, but I expect that in a month or two months that it'll be much less. Okay, cool. I mean, if in case you haven't seen it, I'll try to find it in my handbook. I mean, people that are contributing to EE if you need a license, I mean, here's like a handbook page link where you can, I mean, obviously anyone can start out with a free 30 day trial license. And then if you need licenses beyond that feel free to ping me to help with the license. And I mean, the other thing I talked to contributors about is that actually in terms of like submitting an MR, like you don't typically need an enterprise edition. You typically need it when you need to do testing locally and so forth. So it shouldn't be a blocker in terms of getting people started, but I'm just led me or Tim now that if you get stuck with the license issue, so you don't have to deal with that. So I just followed that link. So the link to create an access request issue that... Yeah, that one's internal. I mean, that's something that I'll deal with. So you don't have to worry about that, but I just want people to know that you can always like reach out to me or ping me and then I'll do the internal work for actually getting the license, but that's pretty simple. It usually takes me like five minutes to get people licensed out via email. So yeah. And I mean, the other thing I was thinking, Tim, on the issue for the office hour today, I mean, if you want to like quickly remind people about like some of the low hanging fruits, I think that might be... Yeah, yeah, that'd be great. Especially for folks watching the hackathon. So I'll share my screen briefly. So every month when we have these office hours, we create an issue. And then the issue we link to some suggested contributions and we have identified as some low hanging fruit as well as some bigger projects as well. So in terms of low hanging fruit, we have... Oh, don't we have this already? Okay, let's just get to this one. So enabling support for publishing and installing packages, new get packages using the job token. So this is a good opportunity to get familiar with where the package registry code lives and also some of the authentication code for GitLab. So if you're interested in those things, that's a good place to start. And we have a few examples of some issues with Jupyter Notebooks. These are more front end focused issues with issues where images aren't being displayed properly or things like that. And then for the bigger projects we have, you could always do what Ethan's doing, which is adding in a new package manager format. There's a few dependency proxy issues here, adding authentication support. So the dependency proxy will work with private projects. And then extending the Maven repository to work with the group at the group level. We just talked about identifying that a package is linked to GitLab project today. And then there's a backstage issue there. But yeah, this is a good place to go. Another, you could always of course reach out to me though and ask for if you're interested in working on more issues and you don't see something here. Stop sharing. Just doing a quick query. It looks like there are 10, I mean a lot of them are obviously from Ethan, MRs that are open from the community for the package stage, which is great. Yeah, I know it's, we've been seeing a lot more community contributions recently, which is awesome for me. And I think it's a great team to work with. Come talk to Steve and Nick and I and we can help push these merge requests through. Steve, Nick, Ethan, Tim, anything else? Or I guess if not, I guess we can just wrap things up early. All right, well, thanks everyone. We'll obviously we'll figure out a date for probably like middle of June. And then we'll do this again. Yeah, maybe June 10th or the 17th. Yeah. Yeah, we'll create an issue and we'll figure out a date. Okay, cool. Thanks. Thanks everybody. Cheers. Bye.