Troubles with LocalProject

Since we are not satisfied with the state of the LocalProject class, it would be nice to write down the problems. Feel free to add your specific problems and ideas about the ideal solution.

List of problems:

1. We are not sure, what will be calculated.
2. Name of the class.
3. Located in packit project. (Move to ogr.)
4. https://github.com/packit-service/packit/issues/348
5. Auto refresh/recalculate parameters on parameter change (@dhodovsk)
6. Is there a need for documenting the calculation order? (@dhodovsk)
7. No support for forks.
8. Anyone can improve LocalProject (even though it’s Franta’s baby)

See https://github.com/packit/packit/issues/343#issuecomment-1039035185 for the proposed solution

[FrNecas]

We’ve discussed this a fair bit on Packit hackfest so I am reopening this issue, here are the main outcomes of the discussions:

The ways how we currently construct the object (inputs):

• working_dir + ref
• project URL + PR id
• working_dir + git_url + instance of ogr project
• working_dir + ogr project + ref + PR id

The methods of the class can be grouped into 4 categories:

1. Can be safely removed

• git_checkout_block = unused context manager from the past

1. Can be removed with some effort (just wraps git.Repo operations)

• stage
• push
• reset
• rebase

1. Object construction:

• refresh
• _parse_*
• …

1. convenience functions (mainly git helpers)

• checkout_pr,
• checkout_ref
• commit
• merge_pr
• processing of diffs, …

We should really remove 1) and 2) since they are pointless, this will slightly simplify the class. We agreed that separating the construction logic to a builder class sounds like the best way to go since it will also remove the whole 3) from the class itself making it contain only the git.Repo + remote API from ogr. As for convenience methods, some could stay, some could be taken out to a function, that’s up to consideration.

This goes against the idea of auto-refresh as was mentioned in the opening comment of this issue, however this should not be a problem. If one wants to change something in the repo dynamically, constructing a new object using a builder (perhaps by passing to it the old object + something extra) should be easy enough.

As for the builder implementation, we should be explicit in specifying what we want the class to calculate to avoid this weird obfuscation that some magic calculations are done in the background. Take a look at the comments above for example builder calls.

@lachmanfrantisek anything else to add here?

[stale[bot]]

This issue has been marked as stale because it hasn’t seen any activity for the last 60 days.

Stale issues are closed after 14 days, unless the label is removed by a maintainer or someone comments on it.

This is done in order to ensure that open issues are still relevant.

Thank you for your contribution! 🦄 🚀 🤖

(Note: issues labeled with pinned or EPIC are never marked as stale.)