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

Unified project repo's with all-repos #3

Open
foarsitter opened this issue Feb 26, 2024 · 4 comments
Open

Unified project repo's with all-repos #3

foarsitter opened this issue Feb 26, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@foarsitter
Copy link
Collaborator

I would propose that we unify all the repositories under the py-pdf organization with all-repos. I would like to see that within the py-pdf organization projects the same tools and configurations are used where possible so the possibility arises to make adjustments cross-repo with all-repos.

This gives us the benefits that all the maintainers now how to run the tests and do some maintenance tasks like updating a python version and extending the test-matrix because they are familiar with the project structure without knowing the code.

@foarsitter foarsitter added the bug Something isn't working label Feb 26, 2024
@stefan6419846
Copy link

I do not think that this makes sense in the short term: The projects tend to be different enough (for now) and I do not really see the need to do cross-project adjustments for now.

As it stands, we have fpdf2 with setuptools, pypdf (and pdfly) with flit and pypdf_table_extraction with poetry.

While there might be shared resources/experience, I would argue that this rather is about factual than distribution-specific stuff. Enforcing specific rules or build pipelines is already represented by corresponding GitHub workflows - I personally tend to have a look at the contribution guide for specific rules and then just let CI tell me what might need further adjustments.

@bosd
Copy link
Collaborator

bosd commented Feb 27, 2024

I agree, Ideally we would utilize the same toolset within al repo's.
I have not evaluated yet if that is possible.

On the other hand, it is good to get started here and have some mechanisims in place.
Which covers #2.
Some linters, pre-commit stuff, ruff, tests, autopublish to pypi.
@foarsitter I remember you had some ideas about this in the other repo.

@foarsitter foarsitter added enhancement New feature or request and removed bug Something isn't working labels Feb 27, 2024
@foarsitter
Copy link
Collaborator Author

@bosd I used the cookiecutter-hypermodern-python to scaffold the previous fork and merged back in the source.

Here is a detailed list of features for this Python template:

The docs contain some tutorials: https://cookiecutter-hypermodern-python.readthedocs.io/en/2022.6.3.post1/guide.html#tutorials

@bosd
Copy link
Collaborator

bosd commented Feb 27, 2024

@foarsitter Yes, the hypermodern-cookiecutter.
It looks very interesting, I researcged a bit about it after you referred to it over the the camelot repo.
Wanted to use it for another project, but did'nt get to implement it yet.

The cookiecutter project you're referring too, IMO still seems the best of the bunch.
Yet, It seems it could use some maintainer ❤️ as wel. (Last commit july 2023.)
(Still supports python 3.7, but nothing newer then 3.10)

We can stull use it as a base. Merge the improvements which are worthwhile from one of the forks here.

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
None yet
Development

No branches or pull requests

3 participants