Rename libary to brother_ql2 or similar

[matmair]

This was initial meant to be a very inactive fork of brother_ql that is just kept running on modern python / deps. It has seen more activity and interest than I though. Feels wired to have inventree so prominently in the name. It seems that brother_ql2 is free on PyPI so my proposal would be to rename it, release under 2 names for a while with a depreaciation notice and sunset the name brother_ql-inventree in a year or so.

Open to thoughts in all directions, I will leave this open for a few weeks at least before taking any further steps.

[vulpes2]

I'm definitely in favor of a rename, since this is currently the most actively maintained fork of the original codebase at the moment. This library has a lot of potential, but having to carry the legacy baggage from the original abandoned codebase makes it pretty frustrating to work with. I understand your concern for maintaining backward compatibility, but it would be nice if we can work out a deprecation plan and start to clean up the codebase a bit more.

Some more notable things that would be nice to have:

• Add a linter config and run basic linting on the codebase.
• Completely remove the already-deprecated module devicedependent.
• A stable and documented API would make the codebase much more maintainable. Anything that is not a part of the public API should not provide stability guarantees, otherwise refactors of any kind would be completely impossible.
• Good separation between library code and the CLI code. The CLI code is still pretty messy and does not serve as a very good example for how to use this library, passing **kwargs into functions like convert() makes generating print jobs outside of brother_ql very messy in my opinion.
• The printer model list needs more hardware info that we can't detect automatically. Printer DPI info should ideally be explicitly specified to ensure accurate printing, especially for PT series printers.

[matmair]

I am in general agreement. I consider everything that exists right now as the public API as there was no official distinction made before.
A good first step will be to add some surface testing that will serve as a measure to keep the API stable. After that, I will probably formulate an official contributing guide that contains the principles for the library.

Another thing on my mind is to de-couple this repo somehow from the commit-graph of brother_ql. I have already fat-fingered PRs a few times onto brother_ql and would like to remove that possibility.

[vulpes2]

The only way to detach a fork on github is to delete and recreate the repo unfortunately. I would recommend just creating a new repo with the new name and replace the readme here with a deprecation notice linking to the new repo.

[matmair]

I have created a placeholder repo and reserved the brother_ql2 name - will wait a few weeks for more input and than start addressing the topics here.

[5shekel]

The only way to detach a fork on github is to delete and recreate the repo unfortunately. I would recommend just creating a new repo with the new name and replace the readme here with a deprecation notice linking to the new repo.

just found out you can ask github to detach a repo, keeping all issues and child forks intact. you have to contact support and there's a "visual assistance" (bot) that handles generating the required ticket.
https://support.github.com/request?q=detach+fork