Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor amp-resolver #99

Open
wangeguo opened this issue Nov 4, 2023 · 6 comments
Open

Refactor amp-resolver #99

wangeguo opened this issue Nov 4, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@wangeguo
Copy link
Member

wangeguo commented Nov 4, 2023

No description provided.

@wangeguo wangeguo added the enhancement New feature or request label Nov 4, 2023
@wangeguo wangeguo moved this to 🏗 In progress in Amphitheatre Jan 24, 2024
@AryanGodara
Copy link

@wangeguo Can you please elaborate on this issue? Is this to use a better design patter or is there a bug that needs to be fixed? (Just interested to know more here 🤔 💭 )

@wangeguo
Copy link
Member Author

@wangeguo Can you please elaborate on this issue? Is this to use a better design patter or is there a bug that needs to be fixed? (Just interested to know more here 🤔 💭 )

I plan to refactor it, firstly because it only meets the early experiments, it's just a bunch of features and not modular enough, and secondly because more advanced features will be supported soon.

@AryanGodara
Copy link

Cool! That sounds like a bigger PR; I'd love to be involved in this.
I see that it's in progress in the project, could you please suggest a starting point for me to begin working on this :D

@wangeguo
Copy link
Member Author

@AryanGodara

Yes, it is a big work, and in fact, I myself don't have a clearer and better plan yet. I can probably give a goal at the moment:

  • As a core component of AMP, resolver is definitely a separate module from the previous one, and needs a complete engineering plan, module design, and stable interface.
  • It needs to provide more test cases and maintain forward compatibility.
  • More importantly, it needs to meet future requirements, which may require more references to amp Schema and manifest definitions, such as support for loading dependencies (Partners) from local, network, Character CRDs, etc., and to be ready for future Workspaces (refer to Cargo Workspace).

From my point of view, to do this task well, you need to be very familiar with AMP, it is not just a coding level thing, but a higher level of global planning and design.

At its core, Resolver is essentially a "package manager" parser, like Cargo, NPM, Maven, Go Mod, that assembles flat [partners] into a directed acyclic graph (DAG) of dependencies, which is consistent with a parser's general properties of a parser.

Here are some references for more information:

So, if you want to get involved in this task, it may take some research, and it is not too late to suggest some options or ideas in this Issue, and we'll discuss this task a bit more fully before we do it. Expect some surprises!

@AryanGodara
Copy link

@AryanGodara

Yes, it is a big work, and in fact, I myself don't have a clearer and better plan yet. I can probably give a goal at the moment:

  • As a core component of AMP, resolver is definitely a separate module from the previous one, and needs a complete engineering plan, module design, and stable interface.
  • It needs to provide more test cases and maintain forward compatibility.
  • More importantly, it needs to meet future requirements, which may require more references to amp Schema and manifest definitions, such as support for loading dependencies (Partners) from local, network, Character CRDs, etc., and to be ready for future Workspaces (refer to Cargo Workspace).

From my point of view, to do this task well, you need to be very familiar with AMP, it is not just a coding level thing, but a higher level of global planning and design.

At its core, Resolver is essentially a "package manager" parser, like Cargo, NPM, Maven, Go Mod, that assembles flat [partners] into a directed acyclic graph (DAG) of dependencies, which is consistent with a parser's general properties of a parser.

Here are some references for more information:

So, if you want to get involved in this task, it may take some research, and it is not too late to suggest some options or ideas in this Issue, and we'll discuss this task a bit more fully before we do it. Expect some surprises!

Wow, I'm sorry I completely missed this. I'd been caught up with university exams and job interviews 😅 .
This looks like a big issue, and I might not be able to dedicate enough time for few weeks. I'm really sorry for taking your time @wangeguo 🙇🏼

@wangeguo
Copy link
Member Author

wangeguo commented Mar 6, 2024

@AryanGodara That's okay, it didn't take me too long, and it helps me make this task even better, so feel free to join in the discussion when you have time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: 🏗 In progress
Development

No branches or pull requests

2 participants