I'm looking to settle the namespace for a project (with the working title 'hump', verb not noun). Tentative description:
*::Hump - Perl project manager and command line valet I should note, before going further, that I am biased in favor of test driven development (TDD). I prefer Git as VCS. I develop on Linux with the GNOME desktop. Although I use CLI tools extensively, I see merit in well-written GUI tools, too. The project I intend is related to IDE but with a different emphasis. I don't intend to write another editor; at this level of abstraction, I consider each file to be a unit. Rather, I'm concerned with overall project structure. Partially, this is related to build automation. Please note, before I go further, that I don't intend to develop this project by the waterfall model. Requirements may change as development progresses. Here is only a starting point. * Problem: I see at least six different contexts in which a project may exist: * Local development: Files (tests, modules, scripts, and others) are edited; tests are executed; changes are recorded in some VCS. * Local deployment: The project is deployed on localhost as if deployed by user. For various reasons, there may be some departures. * Remote development: In the case of a project designed to run on some remotehost, files are uploaded and executed remotely. Logs and other result files may be downloaded to localhost. Remote execution may be normal or modified. Structure depends on server requirements and account permissions. * Remote VCS repository: Project is maintained on, e.g., GitHub. Developers may pull, fork, push, etc. I expect that many developers will only be interested superficially. All have certain structural expectations. * CPAN tarball: Project in installable state. Must contain all files needed by user. Structure must be highly predictable. * User deployment: User installs from tarball, either locally or remotely. Installation should be automatic by default but permit a degree of customization. If every project ran directly out of the same tree in which it was developed then existing IDEs would be sufficient. But 'hump' is not a fine-detail IDE; it's a tool to move a project across contexts. * Example: Tests: There may be unit tests, integration tests, author tests, user tests, good tests, bad tests. Some tests do not pass now but will later; meanwhile, developer does not want to run them as part of his regression suite. Some tests examine the execution environment and bail out of further testing if prerequisites are not installed. Some tests are useful during development but are strictly optional for user. Some tests are failed testing efforts; developer may want to keep them around. They may later become good tests or may stay in the junk box. For each of the contexts I mention above, tests must be organized differently. Broadly, localhost development contains all tests while other contexts contain subsets. Remotehost development context includes tests that are only meaningful as they interact with the remote server and perhaps the network and there, these tests run right along with the others; while localhost cannot usefully run them as part of a regression suite inside the inner test-edit-test development loop. In VCS repo context, good tests and correct-but-failing tests should be kept distinct from tests that fail because they're badly written but may be rewritten (to pass or fail depending on the item tested). Tests required to assure correct installation and perhaps some optional tests should be packaged in the CPAN tarball, but must be kept clearly distinct from one another. And most users will not want to permanently install any tests; while others will want to keep them on hand. Mindful of brevity, I will omit further examples. I only make the points that a project may contain hundreds of files in localhost development working tree; and that the trees in other contexts cannot be obtained merely by pruning. Sometimes, the overall structure must be altered. Even in the case of simple pruning, the rules for which files and folders are to be removed are complex. * Tree management: Let us turn to *how* the tree is copied from one context to another. Many tools share out this work. Various CLI tools may be used to make quick local installations. Git contains actions to push to remote repo; untracked files will not push. Perhaps rsync is used to transfer files from localhost to remotehost development. Module::Build, guided by MANIFEST, controls creation of the CPAN tarball; as well as testing and installation by user. There's an issue in coordinating these trees in different contexts. It can be difficult simply to remember the command line incantation needed to shell into a given host or to update MANIFEST. * Project role: To sum up, 'hump' is intended to streamline the process of project development, particularly by managing the various working trees. Some contemplated features: * Maintenance of metadata for any file or folder, including: ** contexts in which it should exist at all ** its proper location in each context ** author's notes * Shortcuts to tools that transfer files from one context to another. * A library including both file templates and tree templates. * A method of deconstructing an existing project into templates. * Flexible, clear methods for customizing all features. * Most "heavy lifting" done by invoking existing, well-tested tools. I imagine a GUI tool with multiple panes. On one row, several panes resemble Nautilus panes, displaying file trees, one pane per context. Connections among panes might be shown; trees might be compared. On another row, a large pane emulates a Terminal, while to its right are several customizable buttons for common tasks. It should be possible to preview at least some command line actions before invoking them. Some features of this tool might be implemented as CLI commands. I don't want to displace tools such as Module::Build; but there may be a role for a small deliverable to assist user in customizing his installation. * RFC: My first need here and the primary goal of this RFC is simply to namespace the project. My feeling is that it's unwise to change a project's name after significant development on it. While I'm sure many will want to comment on the proposed feature set, I'd like to ask that such discussion confine itself to defining the role of the project; so may its proper name be discovered. Thank you, -- -Xiong
