iplib3 VS Tsukasa-credit-card-gag-scam

Instead of keeping all the code at the repository root, maybe consider a more traditional project structure. As far as examples go, I've got this for an executable, and I think this works for a more complex project.

What that means in practice, I have yet to figure out how to explain in the simplest way possible, but perhaps an example repository might help somewhat. The details more or less boil down to

First, some values simply never change. For example, my iplib3 has plenty of hard-coded constants set by the IPv4 and IPv6 specifications and there's no need to have those in some external config file because, again, unless the standard gets updated those are constant.

I haven't touched this codebase in a while (although I really should), but it serves as one of my better examples for object-oriented programming. It's reasonably large, yet meticulously linted: https://github.com/Diapolo10/iplib3

I don't have any projects using setuptools anymore so unfortunately I can't give an example for that, but if Poetry is fine then iplib3 will probably suffice. Focus on the imports and the project structure, and maybe pyproject.toml, everything else is just noise.

Well, my GitHub profile is part of my flair in this subreddit, feel free to dig around. My latest project was an attempt to port the ms JavaScript library to Python, and I think I did alright. Other things I can highlight would be my iplib3 package, a server implementation for the EguiValet messaging service, and finally I've got a fairly unfinished text colouring utility called escapyde.

And iplib3 could use some cleanup, such as redesigning the inheritance to add support for seamless conversion between all supported types. The documentation should also be written as right now there's basically nothing.

You could maybe take a look at my iplib3 project for some examples. Alternatively, the EguiValet server project should be fine too.

While I have a very recent project that would otherwise be a perfect example, it does something a bit unusual with imports so I'll instead use iplib3 as an example, even though I haven't had time to work on it lately.

The Pytest documentation does a much better job at explaining how this works in practice than I ever could. I don't have any super simple example repositories, but iplib3 might work: https://github.com/Diapolo10/iplib3/blob/main/tests/test_address.py

One workaround that I can think of would be to build everything using GitHub Actions, as then your own system would not matter at all. I have a great example project for that, all you really need to do is create a YAML file in a directory called .github/WORKFLOWS (the filename itself doesn't really matter), you can use this as a base. Just gotta swap out Nuitka for PyInstaller (if you want to), and change how the dependencies are installed. This makes it so that whenever you push a Git tag with a version number (say, v1.0.0), GitHub will then run this script, build executables (on any operating systems you want, no less), then create a release with them available for download. Mine also adds a changelog, but you can just remove that part.

If your company uses GitHub or GitLab, be it internal or the online version, you could create a release on the project page with your built binaries attached for download. One of my projects should work fine as an example. The releases page is linked on the sidebar. The neat thing with this is that you can automate the whole build and release process; I get a new release whenever I push a Git tag with a version number.

Ideally you'd make your project "installable", and use absolute imports for everything. This way, when your project is installed as a package, assuming there are no circular dependencies any part of it can import from any other part. Mainly this makes the job of your unit tests a lot easier. Either of these two examples will probably showcase that just fine.

However, if that's not the case for your project, such as if you have an extra src directory separating the repository root and the package(s), you'll need to be explicit. In another project I did exactly that:

I used it in this project as a test, before I made the decision to transition all my projects from Pylint and Flake8 to Ruff: https://github.com/Diapolo10/Tsukasa-credit-card-gag-scam

One of my own projects handles this with a function, which then gets used thorough the program:

Instead of keeping all the code at the repository root, maybe consider a more traditional project structure. As far as examples go, I've got this for an executable, and I think this works for a more complex project.

None of my current projects build platform-dependent releases, but I think this example is close enough. It would just take some tweaking.

I did something like that myself. I found Bleeplo's video about an attempt at recreating a certain meme image as a real tkinter program, and I enjoyed the idea so much I ended up making a fork of the project, improved upon the original, and even made a pull request to the original project with some of my cleanup. Forked projects always link back to the original, and all forks are visible from the original's settings.

pyproject.toml already lists the dependencies, requirements.txt is not needed nor used in the newer standard. In fact, it can list your development dependencies as well, like here for example.