Description
Using code in conf.py to automatically pick up new example files.
Privatize all Pydantic model and field validators.
Rename replaces to replace for consistency with load_sample.
Some security concerns with Sphinx and various private projects.
Output from the workflow enumerates the Python package directory tree.
Change the link on Sphinx badge to go to documentation instead of output.
Actual documentation produced covers items outside of the scope IMO.
Using conclusion: success with the Documentation workflow pipeline.
Soo many objects completely lacking or lacking advanced parameter validation
Removing # NOCVR on all the params __init__ which I do by default
Removing # NOCVR|NC(Nne|True|False) to validate they are still relevant
Consider naming of extra functions that aren't meant for use outside of module
Forgetting to update requires when updating projects that use each other
Get the pins updated and add as a step to README.md Version management
Seems I could have been using @staticmethod in several places for various helpers
Consider the _variables which are used outside but mostly inside a module
I have seen some that are not top of file, but above their class or function
Reuse of common arguments within the execution area of various projects
Awhile ago an LLM indicated I needed to mention py.typed in MANIFEST.in
Are there any other files that I should consider adding?
Validate nothing is missing from Sphinx and choose better template
Whether or not and/or when to import from __all__ exports within the project
Proper use of defaults in argument parsing, Fix for an immediate issue enhomie#90
Some downstream HomieChild classes have params method and some do not
Some downstream RobieChild classes have params method and some do not
Can Sphinx deal with imports found in if TYPE_CHECKING or is it lost on those?
Using unitime to simplify anything defined by seconds on a large scale
Improving the workflow; does Documentation run even after Validation failure?
Improving the workflow; can I receive an email when coverage is not 100%?
Improving the documentation; looks horrible; my fault or broken template?
Improving the documentation; present output from cloc and other statistics?
Looking for and updating common parameter descriptions, possibly use an LLM
Decide correct strategy for linking PRs and retroactively update where possible
Link in Development; closes issue with PR
Refer to in Comment; does not close issue
Wish there was a better way to know if in console mode than sargs.get('console')
Inconsistencies and wonkiness with docstrings in commonly named methods, classes
Start by looking at the child objects in enhomie, enrobie, and orchestro.
Examine coverage exclusions inline but also within project setup.cfg.
Re-encrypt values in configuration files so that all instances using unique key.
Move commonly defined importer function into encommon, and improve upon.
make outdated will leave behind a file in require/ folder.
Reactions are currently unavailable
You can’t perform that action at this time.
replacestoreplacefor consistency withload_sample.conclusion: successwith the Documentation workflow pipeline.# NOCVRon all the params__init__which I do by default# NOCVR|NC(Nne|True|False)to validate they are still relevantrequireswhen updating projects that use each otherREADME.mdVersion management@staticmethodin several places for various helpers_variableswhich are used outside but mostly inside a moduleexecutionarea of various projectspy.typedinMANIFEST.in__all__exports within the projectHomieChildclasses haveparamsmethod and some do notRobieChildclasses haveparamsmethod and some do notif TYPE_CHECKINGor is it lost on those?unitimeto simplify anything defined by seconds on a large scaleclocand other statistics?sargs.get('console')enhomie,enrobie, andorchestro.setup.cfg.importerfunction intoencommon, and improve upon.make outdatedwill leave behind a file inrequire/folder.