As development continue, some more modes will be needed. It clearly better to split in sub commands for each modes instead of mixing every modes and their options in a single commandline.

Also think about to rely on Click to make a new commandline, Click dependancy may be harmless and safe ?

The project need a solid documentation to demonstrate the system to ensure adoption.

• Overview
• Basic raw Python project sample to demonstrate the base;
• Enable missing core module code with autodoc;

• The 'Basic sample' document has some typo/wording errors;
• Example codes may have some typos also,
• Some parts may be more accurate or helpful;

The command should open the manifest and check for some parts like settings, urls, requirements, etc.. This would be very helpful to diagnostic invalid manifest, path structure, etc.. in case of troubleshooting.

Each app could contain a .env to describe available environment variable that can override the app settings.

The manifest plugin will probably have the same options than the requirements ones.

A new commandline (dotenv) will be needed to compose the final .env file for the project. However it may be created to another filename (.env.composed) to avoid overwriting the .env file that user created to define their effective env vars.

Resolved applications and following parts from check output does not have the properly ordered apps as it should be. At least from what i've reproduced, the PUSH_END is not respected, probably also the dependencies.

And finally these app listing are ordered from the natural collection order and this is troubling because in these parts it would be expected to show the right expected final order.

It's weird since what i saw quickly in helper code, the resolving order method is called.

A command that will remove every applications that are not enabled from manifest.

This is too help those ones which want to clean useless application, like for a project that won't never need CMS, just a DRF, this will help to remove all CMS stack.

It will need to be an interactive command that will ask for confirmation since there won't be any turn back (except with a vcs).

It could be nice to have a feature to manage multiple compose environment.

As the environment settings is commonly done, the main compose config would be the default base and possible additional environment would inherit from it and override necessary var.

Still need to find how to manage it well from compose manifest in YAML file, how everything could adopt this feature and if it is not wrong idea that could lead to messy things.

• Fill composers options (appsdir, --syspath, etc..) directly from manifest ?
• Support YAML format ?

The first scope of this project was Django even it can do more, but for now we need everything for Django usage.

• Documentation by samples ?
• Helpers for integration in a Django project ?
• Django commandlines ?
• A new package dedicated to Django integration helpers/CLI ?

This needs at least:

• Overview
• Basic raw Python project sample to demonstrate the base;
• Django project sample to demonstrate a more concrete usage;
• Enable missing core module code with autodoc;

The 'merge' would be able to override manifest settings attributes with given parameters in a dictionary.

This would benefit to CLI that currently have to implement it themselves but the settings and arguments types does not have the same behavior (None is fine, but empty list from syspaths overwrite settings which is wrong from cli arguments).

The method currently emit a warning log when not finding part module from apps.

It pollutes output for unnecessary noise since it is totally fine that app misses some modules, it is somewhat the concept of composer.

This should be emitted through a DEBUG level instead.

Many importation code rely on ComposerBase.get_module_path() to get the module path to import. The problem is that the method use the _MODULE_PYTHONPATH attribute to build the path.

But _MODULE_PYTHONPATH is designed to be overwritten by composer inheriter (django, textcontent, etc..) to directly point to a specific application module (settings, urls, etc..).

But now with collection order resolving, the composer always first go to scan application module (its __init__ file) to search for app parameter variable like DEPENDENCIES, but when using a ComposerBase inheriter like ComposeDjangoSettings the module path is not right since _MODULE_PYTHONPATH have been overwritten to search for APPLICATION_MODULE.settings and so it is unable to find the application parameter variables.

So currently, the application order resolving is broken with ComposerBase inheriters.

Some application like DjangoCMS need to be loaded last in urls. Also some application may depend from another, like DjangoCMS depend on file manager and ckeditor.

The full centralized map is not a very nice solution since it involves to know every applications and to be managed.

I would want to try something like the migration system where every migration explicitly declares their dependencies, so anyone can create a new application and declare the involved dependencies, it's more flexible.

Also there should be an additional flag like PUSH_END to enforce an application to be loaded last but respecting dependency order if another dependency ask to be loaded last.

These options should live in the __init__ for each application so it can be easily discovered from composer before any mode (requirements, settings, etc..).