Use natural order of task names when listed #207
$ doit list buildhtml Build HTML documentation. buildpdf Build PDF documentation. publish Publish documentation to FTP. spell Spell document source files.
Tasks are today listed in alphabetical order.
As seen, it can look quite confusing and user would appreciate natural order:
$ doit list spell Spell document source files. buildhtml Build HTML documentation. buildpdf Build PDF documentation. publish Publish documentation to FTP.
I guess, changing order of listed items is not likely to break anything and I would prefer do it this way by default. Author has good control of order of tasks definitions in dodo file.
If alphabetical order would be (sometime) required, we could add a key "listorder" into
I had similar issue with Click pallets/click#513 (and I managed to resolve it).
The text was updated successfully, but these errors were encountered:
@vlcinsky , just my 5 cent for this issue.
Actually, the alphabetical order is much useful when list of your tasks counts above hundreds of names.
Also, alphabetically ordered list of tasks is much helpful in auto-complete tools. And you know it, there are no time at all for additional sorting in case of auto-complete. The word have to be completed just as typed.
So, my opinion here is that the order have to be alphabetical by default. But, indeed, the configuration option would be good, as well as command-line argument for
Great comment @FrankStain
I wonder, where so high number of tasks in your case comes from, I can think of two sources: number of specific tasks and number of files (or other types of items, which usually populate subtasks).
Regarding tab completion: I consider tab completion distinct from listing and the purpose is a bit different so alphabetical order seems to be the best option.
@vlcinsky , i'm professional game developer. Also, i support my own huge game framework written on C++. :)
So, the large scalable build systems are the game building automation tools. It consists of game binary image builders for different platforms, including cross-compilation of source code and source code generation from some DSL schemes. Also it consists of resource generators, where a lot of resource types (dozens of types: textures, 3d objects and scene graphs, sounds, database and state machine raw data) have to pass through dozens of compilation steps. After all, such build system consists of dynamic testing tool, which makes some tests on build target before make it published for Draft usage, QA or Retail customers. And, yep, publishing/QA deployment also implemented as part of build system.
Just imagine you need to read PNG into pixelmap, compress it into ETC2, ATCI, S3-TC5/BC3 and PVR-TC4, after what each of compressed texture should be placed into different resource pack, obfuscated and encrypted. And all is done by different tasks, cuz i can read textures even from database, zip-file or other pack and may not wish to compress it into some formats.