 So I think we should right now start with what we have to do with the image it the most thing we have in priority and that's the get to choose it and so the status with get to choose it is that it's the business logic is mostly done I think Fran has reviewed the latest commits and apart from one or two optimizations he was saying that we could do you're saying that functionally the PR looks okay and I have added six test cases automated test cases where I the cases the range from using existing cash if you have cash it calculates the size, then we have cases where we have one extension, two extensions or if an extension is throwing an exception. So I have some cases I've covered some of the basic cases for the class. I'm sure that we need more cases there. Now the one of the one of the major blocker I was thinking with that PR for merging it was that it does not stop. It doesn't it recommends jagged when it should not. So we're not we were not looking for LFS checkout and spark checkout and for those extensions we need to we need not to recommend jagged. So for that I've come up with a solution I haven't submitted it but I just wanted to discuss it quickly so that I just know that I'm going to the right direction so I so what I have done is that I was looking at so it's since both of them. The get LFS poll and these past checkout both of them are get SCM extensions. So what we can do is that we can add another responsibility give another responsibility to the get to choose it that it. It asks the so what we do is just a second I have the get SCM extension class I need to open it so we decorate our clone command checkout commands and another many other operations we need for whom we need to modify the behavior. So we could add another decoration tool here where we decorate the tool the get tool. So what we do is that while we're we're in the process of recommending the get tool. We could search for the extensions available get SCM extensions in the project and then since this will be implemented by two extensions and that would be LFS poll and the spark checkout I could ask for. So what I was thinking was to ask for a map which would have implementation and a Boolean which would tell if the implementation is supported or not. So for sparse checkout it would say get true jget false and for get LFS it was it would also say the same thing. And then in my get to choose it I would check if my the recommendation I have given if if the Boolean for that recommendation is false from that from the from the separation of extension and checking. Then I would not recommend jget or I have kept it general if for any case in the future I'm not sure if get has of course it doesn't. There's no functionality with get would not work this get is providing the functionality is jget jget would have to clone them but still I've kept it general if for some any case get is it has it's it's it's a case where get should not be recommended. We could add that to the map. Now my concern I think while discussing it is since this is a fairly new thing I was developing. So I've come up with a problem with my own solution right now and that is that what if multiple extensions are giving different decisions. That would be a problem what if someone says jget is false it's not supported but some other for the other extension it is it is supported and if it's implemented there. That would be a problem if it's not ideally it should not be implemented where the extension doesn't have to worry about support supporting and implementation or not but I guess that could be a concern. I'm I'm I'm trying to comprehend here so the, the responsibility to know that by the way, as a word of warning, there are more get SCM extensions that are not implemented in jget than just the two that are listed. So, it's, it's sparse checkout is not implemented there are several others. So, so it this is it's not just a case of two, there will be multiple. There are there are more than that. And so I think that what you were proposing is that the responsibility to answer the question. Does this get SCM extension work with jget or is this implemented with jget is is delegated to the extension or are you and seeing it would be handled by the by the get tool chooser to just to know which extensions are implemented and which aren't with the extension. So, so the, the jget implementation that put today puts up an ugly error message and says sparse checkout is not supported, or something like that, somehow needs a way to inform get tool chooser that I am jget I can't do what you want to do you cannot pick me. Yes, and I was thinking as a string and a Boolean map, something like that. Passing that information using a map with the string would be the implementation and the Boolean would be the So, for an example I was looking at get LFS pull so we know here that so we so this LFS remote is the variable which tells us if if for jget it's it's not we don't I think I was looking at some implement I was looking at jgets implementation and for jget this is none or the point is that we at this extension we could have the information where we know that jget can be supported by this extension or not but at the level of get tool chooser it would we would have to do a lot of work to understand if that extension we would have to hard go some kind of rule I'm not sure how would we know that the extension is supported or not but at the extension level we already I think okay we don't we don't even decided the extension level we decided once we go to CLI get implementation or the jget implementation at that point I think we've made the decision if at jget we basically just throw an exception I was seeing the code we throw exceptions when we when we see variable like LFS remote or sparse checkout path. So, I think the decision to delegate the responsibility to the extension ask the extension if it's supporting or not is is I think logical in this case, instead of letting get to choose getting that responsibility. So, so get tool chooser then asks, or, or has two alternatives, I guess three alternatives right now it could choose jget API Imple, it could choose jget API Apache Imple, or it could choose CLI get API Imple right so those are the, those are its three choices. And, and a specific job has a collection of a of get SCM extensions associated with that job, I think, right, where a specific checkout or a specific context where we're running. We're about to use get tool chooser to offer them choices, and the choices could be at most one of three. Yes. So, could we, could we ask the CLI get API Imple, he or could we give the CLI get API Imple, and the jget API Imple, the, the set of extensions that are being requested and ask them do you veto. You're being offered as one of the get tool choices. I'm. So, back to, I'm not sure that I'm, I'm comprehending where you're envisioning you would put the, the, the knowledge of. Okay. I think I should explain this a little better so let's just go to get SCM first. So, when we're looking at get SCM this is the function we used to create a client this is called when we're checking out a repository. So, for the demo I tried this this right now we're not, we haven't added anything where we would recommend jget. I would not recommend jget if we have LFS or sparse. So, here what we're seeing is that I get the, I'm not, although technically this is not being used now. So, usually we get the, the executable from a function. And then, so what I'm doing is I'm calling my, I'm calling my estimator. Yeah, so I'm calling the get tool chooser here with the URL, I take the URL from the remote config. And after that, I get the get tool and I assume that it has resolved the implementation recommended with by checking if it's available or not. All of that is being done and then once I have that execute the recommendation, then this is the stage where get client, get client is created in the next stage but this is the functionality which creates the get client. So, here I just put the recommendation using get exe exe and then the client is created. And so I think I would, I would assume that once we've done that we are covering all the cases for the get SCM class anywhere a client would be created would be created with this recommendation. Now, if you're talking about checking if, if the implementation is supported by the extension or not, we would, we would, we would have to do this, we would do, we would have to do that at this level only. Because I, because we, we need to instantiate get tool chooser just before the get client is being created. So I, I think this is the place where we would have to use the tool chooser and we would have to then ask the extensions if they are supporting check. So what I'm saying is that we know that it is, is this something that we can hard code that for let's say just for get LFS pull, we know that it's not supported by JGIT. Can we just not say that, okay, this is going to be false for JGIT always and just return that to return that to get tool chooser. And as get tool chooser, I would be sitting and looking for looking at the extension. And if I receive a false from anywhere, I would block the recommendation and not give anything. Yeah, and I think, I think, I think that is that is that would, if you go back to the, to the function you had there just a minute ago, the, the one was iterating extensions. Yeah, so online 868 where it iterates over the extensions to take your, your idea I was thinking, if estimator dot get tool dot estimator dot get get tool took the, the argument which is the list of extensions. It could conceivably then know everything it needs to about hey I know these things admittedly that's not asking JGIT itself to tell us is this is this implemented, but it would give us a quick way to say inside the estimator. If the, if the request, if the extension for LFS is included veto any use of JGIT. If the request for sparse checkout is there veto any use of JGIT, it must always use CLI get. Yes. So, so in, in that case estimator dot get get tool would take one more argument, the list of extensions, and it would just have a hard coded list inside now that's, that's not my Java coding friends who actually are very good at Java coding would probably mock me terribly. So, I'm, I've just described something to you that looks an awful lot like what a C programmer would do and I apologize for doing that to you that's, that's really bad mentoring but, but it's that kind of thing, I think, I think the get tool, or the estimator needs to I think we need the estimator to not offer JGIT, if an extension is going to break the user right that that's the user value. Now, now, go ahead. No, I was just gonna say, I think that seems like a good way of, of getting this in with, because I think you're proposing to put this in with this PR. So I think that's also a good way to get this in the PR to make sure that this works properly without going too far architecturally like into the, you know, the perfect solution, I guess. But maybe that's not that far away. I like the suggestion of using the estimator and passing that in somehow. To object Reshab to trying to pass in the list of extensions to the get to to get to the estimators get get tool method, and let it use a hard coded list initially. And then if we can find a better more object oriented way to do what we do that but for me, passing in a hard to passing it in and having a checked against a known list of problem and extensions seems simple enough for me to understand it. But I think we we can have something which which we do here so what we can do is that the extensions are implementing the get SCM extension. And if we have a method there which a contract which says decorate the get to which basically means that I encode the information at that level, the extension encodes that if it is the responsibility of the extension to implement that method, which is to decorate the get tool and then say that okay, I'm going to tell you that for jget, you cannot recommend jget if if that extension is present in the list of extensions So how that would work is that let's say I have the extensions I would say dot decorate if it takes what I've done decorate to I've already just created the sample method, it would take my, it would take the to choose if we have, which would be the estimator here. And it what it would do is it would tell the estimator that okay I I cannot take jget and how I was planning to do that was that within the estimator class I can include another method method which is a simple Boolean method which is supported and it takes a it takes a map, it takes a map which links the implementation to its support. So if the extension tells me that maybe we can we don't need to use a map but if the extension tells me that for a string jget false it's false I would just I would not my implementation so what I do is that I check if I am recommending jget and if the extension is telling me that jget is false, I would recommend nothing. Or recommend get that's I didn't think about what I would recommend after that part because then we would again have to look if if I recommend get instead of jget I would have to look I would have to resolve it get if get is present in the mode or not in the machine or not but We could decide that after that point but at this point, instead of taking a list and then hard coding that okay for get LFS pool or for spastic or we're not. We will just not recommend jget we could create a method which would it's basically doing the same thing I think but I was just following what the get plug what I have seen in the get plug in how do we modify. The behavior of clients using the extensions that is what I've seen so I guess I should first submit this as a comment and then we could have a better discussion over this, because I think me saying this would not 100% explain it clearly. I guess one question I have is like. So if I think about the objects. Should the extension know about the get tool chooser. Because right now like the proposals kind of saying that it needs to know about what a get tool chooser is. Yes. And I thought you had added capability to the get SCM extension to know something about choosers right. So what I did was that I actually it's not it's just returning the tool to the right now but so what would happen is ideally that get LFS full, which is implementing the get SCM extension to just override this method and it would. Yes, it would have the object of the current get tool chooser and it would add this information to that object using the utility method I have which asks, is this supported or not. So it, if we, I think we can write it. This is the method I think the method is decorative. So, because really the, the tool I guess is the actual like get implementation is the one that knows what it supports right. I'm sorry, I could not actually I think I think that the individual extensions. Well, let's see how is it, it's J get API, I'll have to, I'll have to look it's good question I thought I thought that the, the noise about when it says hey LFS is not supported is coming from J get IP API able, but I don't remember. Continue. I did, I did check in the J get API input that it would throw an exception if if LFS remote is found. Yeah, people might scream at me though too but I guess I'm just wondering if maybe the extension should know more about implementations that can't use. And then the get tool chooser uses that information. So that the extensions don't have to know anything about the get tool chooser and the get tool chooser already has the responsibility of choosing which which one you're going to go going through all the list and then finding the optimal one and then if that's not supported then you can't pick that one you have to go to go to another one right. So, this is what I was suggest what I had in my mind so so now right now the get LFS pull would add this method override the method decorate tool and would put some logic and tell me okay is it supported or not with the current get tool chooser object and then return the object again and then I can use that updated object and get the get tool and recommend the but even even if we have this functionality we would hard code something like okay for the string J get I am going to say it's false something like that we are going to hard code this information at this level. So it's, I'm not sure if that's a good thing to do, but yeah so I think you're already saying like which implementation doesn't work in this. Right, like that that hard coding right there would kind of be saying that. So maybe the right way of like thinking about it is like that's all you need to do in here and then the get tool chooser can maybe use that information to understand what it needs because the other stuff I guess, and I might not be understanding what you're trying to do with like that is supported. So, yeah, you might be right in terms of like putting it in in the PR. But I guess I'm not sure what the other stuff would do that we would use other than knowing that J get isn't supported here. And so then they get tool chooser would find out what's not support like is this candidate. Yeah, you already have kind of the information you need, I think. Again, but I said someone might yell at me to I'm not the main principal maintainer of this. And I've been in go lately so. Okay, so I understand. So the concern would be that if we are implementing the supported function that we are asking for this information. For get LFS poll and for get for sparse check out then we would have to ask this information for every extension. Yes, I actually did not. I think I'll raise a poll request first and actually write a unit test. I that would be the quickest way to know if this is working or not the best way. The other concern that I have that isn't like that big video but it is something that we try and avoid is like you're, you're putting a dependency. The extensions are going to depend on the get tool chooser. They have to know about the get tool chooser. And I'm not sure that that's a get tool chooser needs to know about them also so we have a cyclic dependency, kind of. And maybe they know too much about each other. I am not sure how the extensions require to. Okay, they because this is an extension. Yes, this is an extension. So it needs it now needs to know about the get tool chooser. I'm sorry I interrupted you go ahead and done. No, that's, that's, that's right. I, okay. Again, that's probably not quite as big a deal as the other stuff that we're saying but you try and avoid it if you can I think, typically, I understand your point I think I've, I think I need to think about this more much more than what I thought. Okay. You might find something cooler than the most. Yes, maybe. I think about it more. So Richard, the, the get SCM extension has been. Are you okay if I ask you some other questions. Yes, Mark, please. So, so the get us, I, I, I apologize for my neglected not having reviewed your PR yet I'm great so grateful that Fran's done it and been working so close with you that's wonderful. In the, in that PR, is it, is it extending get SCM extension. Is, is there an addition to get SCM extension I'm just going to open up the PR now just to see it. I just was wondering, is that going to affect, okay, get tool chooser all whole new class to a chooser test. Okay, so your pull request, your pull request for size estimation does not add anything to get SCM extension. Okay, good. I was, I was worried that you were. Okay, so maybe then I'm back to Justin's question. Talk me through again. Talk me through again the, how do we communicate the, the non support of a particular extension in, in one of the implementations, you're envisioning you were envisioning it, it would be communicated through the decorate tool facility here that you've shown us. Yes. Okay, and so it would ask the get tool chooser. Based on this on the current extension get LFS pull pull is the one we're looking at right now right. It asks the chooser is this supported. And the chooser. It is, it's not, it's actually telling, I think the, the name of the function is not correct, but it's, this is the information which get tool choosen wants it get tool chooser would not have any idea if a certain implementation cannot be implemented because of a certain reason. This is the extension, but to get LFS pull, I, I assume that I assumed that it would have the information to know that it is, it is not supporting jagged. So it would, it would tell, so this way I figured out this way to tell chooser that okay, I cannot support jagged and just know that and then the chooser can decide to recommend. This is either get or nothing. I see. Okay. Thank you for the clarity. I think, I think I've, I'm starting to comprehend your vision. It is that the, the, the get LFS pull extensions, decorate tool method is called, and it relies on get LFS pull to call the chooser that is passed in and tell if it's not supported or not. So it's, it's passing in. Hey, here's a thing, I get tool chooser. Now, extension, your responsibility is to annotate this thing, supported or not supported. If it's not supported, the get tool chooser then says, ah, I will ignore this as an alternative, because it doesn't support this extension that's been requested. Okay. Thanks. Forgive my, forgive my being so slow to catch on. Thank you very much. I think I should have come in the code first. I think discussing the right way. Oh, this, this was, at least it helps me understand the concepts that you're, you're, you're approaching great. It depends too. I mean, I think you're, I think you're fine to, to talk about it. We had the time to so it's good discussion. It depends like it's always hard to figure out like when you should talk about something before you comment or whatever it is. So I don't think anything else like forgive the question, but as not a, not a core get plugin maintainer. That's where my questions coming from. I think this is a new thing that the plugin can do in terms of who knows what the capabilities are. Like, in terms of who knows what get tool has what capabilities. Right. Right. Right. Today, today the plugin, the plugin is actually quite stupid in that it has at least three or four different ways of informing the user that a particular extension isn't going to work. And it's embarrassing how many different ways it has. Let's see. In some cases it will, the extension will throw an exception. If you ask it to use something in others, it just prints a polite little message in the log and says, I'm ignoring your request. And what Rishabh is showing is that that stupid way of doing things that poor way of doing things really needs to be sanitized and brought to a consistent level, because the get the get tool user needs to know, whereas before no nothing else needed to know now something does need to know. And so he's found a concept that it's actually hidden all over in the in the plugin it's an embarrassing and how many different ways it's hidden. It's, let's see, throw an exception, or just give a message or don't do anything just silently ignore it. And those are all completely inconsistent and of course, because of the history of the plugin we have to retain them as completely inconsistent in their behavior, because otherwise, somebody will be broken who depended on that bizarre behavior. And I guess that is the same reason we cannot just recommend jgate for someone who is assuming that get is going to be implemented for a particular use case because then we would break a lot of use cases. Considering that right if if they if they're if they ask for the sparse checkout extension. And we know that jgate doesn't implement it. And they will howl and complain correctly so that all of a sudden we put a lot more data into their workspace that they never intended to be there. And they won't care how much faster we are because we broke them completely. Right, exactly. So, I think, if I understand correctly though to, I think the extensions also are primarily what would know like kind of what capabilities a tool would have at this level. Right. That's usually where you would be handling what what's compatible with what you're trying to do or not. Right. Yeah, so so as an example, Rishabh is get LFS pull the class and forgive my not having it immediately on mine but is get LFS pull the class. That is an implementation that is for both jgate and CLI get or is that only for one of the two. That is something else so forget LFS pull I know that it's an X it extends the get a CM extension. And then once we have to use I what I've seen in the code is that this variable called the LFS remote it's included in both jgate and the CLI get implementation. In the case of jgate implementation I think it checks if it's not null, then it throws an exception, it checks me this was an exception. So, so, so to Justin's point, get LFS pull is the extension, but it's actually not doing the implementation it's relying on jgate API and pull or on CLI get API and pull to do the implementation so so this thing get LFS pull doesn't actually know that jgate doesn't implement it. So all the knowledge about what's implemented or what isn't is inside jgate API input class, or CLI get API input class. This extension would configure the LFS remote variable none of the nest. It doesn't care about the implementation. As Marcus said, only the end the ones we reach to the point where we're implementing the particular when we're checking out the repository and if we have to check LFS remote in terms of jgate it would throw an exception get what CLI get for do it doesn't that hint that decorate tool what you may want to consider is should instead of asking the extension. Should we ask the implementation CLI get or jgate API and pull, because that's where the knowledge is right now. It's embarrassing that the knowledge is right is there right it's it's awkward and flawed that the knowledge is there instead of in the extension but that's where the knowledge is right. So, so maybe we should ask the implementation, rather than the extension. Are you are you a vow are you still a valid implementation based on this set of extensions. It actually kind of seems to make sense really with the implementation also it's like if you had a get command line with that implementation be like a versioned get tool, like a get 1.8 versus a get 2.2. It could be but it is it is that's that's a user description at the and and then that's even more complicated. That's something we haven't touched on at all it is allowed to have multiple input multiple. What do you multiple get tools, but the code right now makes the decisions about capabilities at runtime very very late, it asks the specific get implementation what's your version, and then senses based on that version number. Yeah, I mean I actually kind of like your suggestion of having it with the tool because the tool should know what it what it supports right like. I'm not suggesting that we get this version level thing with taking this even further you could say like get 1.85 doesn't support like this new thing that you want and get 2.2 and then you won't pick that one you would pick 2.2 if that's available or you'd say, I don't have anything that supports us. Right and sorry, the use case you're describing is very, very real Centos seven as the is the poster child fully supported production operating system used all over the world with get 1.8. And of course, yes, all sorts of people use it right I mean, and but latest Debian release get 2.20 latest Windows version 2.28. You know, so, so, and, yeah, we've got a wide range of version numbers and I hope in some future day to drop support completely forget 1.8. But you know that that's not going to happen till Centos seven is dead and long after that so. So in a decade. Exactly 10 years. If we're lucky. Okay, so, so we shop. I'm not sure that my inputs anyway have have helped you a bunch. But I hope they've helped a little as you consider where should the question be answered is this capability available or not. Yeah, I will look I will check how I can access this information from jgrid API implementation. So there is, you're going to you're going to look inside that code, and you're going to shake your head and disbelief mark weight. Nikola Kosake how did any of you think this was acceptable to do it this way that that's yeah welcome to the world. Yep. What code bases that live a long time generally will have some, some skeletons in their closet. Right, you are you are in a skeleton zone. Does this does this have an interface or, or does it inherit from an abstract class that I don't need to go there, you'll you'll figure that out. It does. It does and I'm not sure you want to mess with that but that's up to you yes, there are several right because there was a good API that was implemented many years ago and it provides one thing and it's all deprecated but critically important. And so yes, there are interfaces. No, I don't know if that will help in this case. Shubs, Shubs a man he's got this figured out. And I'll try my best. Okay, I looked into this then. I think time is up for the discussion but Yes, and I apologize. I've got another meeting that I'm supposed to be in so I am sincerely sorry. Yes, you're right. Time is up. Okay, that's okay. I, the one thing that I wanted to discuss was what we want to do for this phase but that's something we can discuss. I think after right now I have worked with the get to choose it so I can do that I'll not be blocked by anything. Okay, so Wednesday, a Wednesday topic then on more detailed planning. Is that okay. Yes. Great. All right. Thank you. Awesome. Thank you so much. Great job again on the demo. Oh, it is a treat working with you. Thank you. Thank you. You make this so much fun. Thank you very much. Thank you so much Mark and Justin. Your help has been great for me.