[idea] extract package for handling recipe-related stuff about haikuporter HOT 8 CLOSED

While it may make sense to refactor HaikuPorter in some way, I don't think we should split it into multiple packages at the base level. At most, we might split it up into multiple modules that can be used independently, but I think we should keep it all in one repository.

What do you mean by "all actions related to recipes", anyway? Most of what HaikuPorter does is recipes; what else is there to split out? "Buildmaster" is already somewhat separate (and should be made more so, indeed.)

from haikuporter.

There are two obvious files related to the recipes: RecipeTypes.py and RecipeAttributes.py, but some functions are implemented in other files, for example checking if recipe is broken for given port is placed in Port.py. Checking, validating, parsing recipes could be placed in one module. It could simplify code base. Keeping it in separate repository can be good chance to make some cleanup and be a way to force people to not create circular dependencies across the files.

In theory one could use recipe package to create a program which will generate proper recipe based on given json input file or something like that.

From my perspective HaikuPorter is doing a lot of stuff - parsing and validating recipes, applying patched, prepares scriplets, communicates with the repository, building ports themselves, etc.

from haikuporter.

Splitting things into multiple repositories won't stop people from making circular dependencies necessarily, since only Haiku will really using these modules in the end.

Yes, HaikuPorter does a lot of stuff, and in some ways it could stand to be better modularized. But I really don't think splitting things into multiple repositories is the way to go, at all.

from haikuporter.

from haikuporter.

Can't we just make the api stable, and keep them as separate python modules in the same repo? It is indeed pretty difficult to work with Haiku packages and package solving without the "real package kit and haikuporter as a whole"

It's one of the reasons I started https://gitlab.com/kallisti5/hpkg-rs (which yeah... i need to dedicate more time to finishing)

from haikuporter.

@waddlesplash
I totally agree with that splitting things into the chunks won't people stop from doing circular dependencies.

@pulkomandy
I would rather propose making cleanup first. I'm fully aware that extracting tools into separate repositories is a very hard work.

@kallisti5
Stable API is a priority! I can start with making some cleanup and starting with solving those circular problems.

Guys, what do you think about making API more stable with proper housework done such cleanup?

from haikuporter.

I don't know what it means to have a "stable API" here. HaikuPorter is a tool for internal use, there isn't much here that is worth "stabilizing" an API for.

from haikuporter.

I'm closing this issue since there are not a lot to do and decision was made - this project won't be divided into separate repositories.

from haikuporter.