Generating directories

Directory generation is usually handled by the manager module. In this case, a target/ directory should be generated with the executable of the correct name inside. Each compilation profile, currently only run and build, should generate their own directory target/run/ and target/build/ respectfully. This will involve modifying manager::generate_project_executable().

In addition to the target/ directory a deps/ (for storing dependencies or files that are needed at runtime) should be generated during project creation (i.e. rectx new project-name). Any files inside the deps/ directory should be copied into the target/build//target/run/.

Milestone reference (#1)

This is the last feature needed for the v1.0.0 milestone to be complete and is referenced on the v1.0.0 section as "Add target/" and "Add /deps".

Tasks

• Generate deps/ during manager::generate_project_directory()
• Generate target/ during manager::generate_project_executable()
  • Generate target/
  • Generate correct compilation profile directory
  • Compile program into target/{run/build}
• Copy dependencies from deps/ into target/{run/build}

Is your feature request related to a problem? Please describe.
Currently validate templates/ and licenses/ by checking if the directory exists. However, there is a chance the directory exists but the files inside do not. This needs to be checked.

Describe the solution you'd like
Within ValidaetConfig() check if there are files within each directory.
Within GenerateTemplates and GenerateLicenses validate the files exist after calls to utilities.DownloadFile have finished.

Describe the issue
rectx template snapshot <folder> scans a folder and produces a .rectx.template file.
The current generation is subpar. Below is a list of issues with the generation:

1. it generates comments
2. it generates a git init . command statement?
3. it reads the project.rectx file and turns it into a FILE statement. This file should be ignored or eventually when #62 is fixed (an hopefully CONFIG or FIELD statements are added the config is translated into that.

Screenshots
Screenshot shows various issues mentioned above:

Problem

Currently, the template system doesn't do errors very well. It will tell template creators if an error exists but not where.

Solution

This is a simple edit to the lexer and parser. Tokens need to keep hold of the line and column of where they are so the parser can use that information when creating BadStatements.

Checklist

• Edit lexer to store line and column count
• Edit token to store line and column count
• Added line and column count to tokens during lexing
• Add line and column count to BadStatement struct

Issue

rectx run will try to run an executable generated by the compiler. However, if the compiler is rctc it will not generate an executable but instead generate a .dll which has to be ran with a separate command dotnet file.dll (reference).

Solution

Detect which compiler is being used and use the correct command to run the executable. This should be a simple fix in manager::generate_project_executable.

Is your feature request related to a problem? Please describe.
None of the commands implemented have had flags implemented yet. The help menu gives a list of commands that need to be implemented. For some commands this will change behaviour, and for others it will simply shortcut the prompts.

Describe the solution you'd like
Implement them ofc

Additional context
Run:

Build:

Run:

Template:

Config (command not implemented yet):

NOTE: All --help flags have been implemented via cli.go and main.go

Is your feature request related to a problem? Please describe.
After #31 will be merged there are still properties in the build/run config that should be added.
Support for these properties also need to be added into the codebase. These include compiler and executable arguments.

Some properties are also not needed currently and should probably be removed.

Project files: config.toml

ReCTx will generate several files and directories on project creation.
Currently, it will generate a src directory storing a main.rct, and a REAADME.md.
Currently the project's generated by ReCTx have no form of configuration (customisation)...

The config.toml

As you can probably guess, the config.toml file aims to store configuration settings, project information, etc...
The config file will be generated by rectx new along with the other generated files and directories.
The ReCT programmer can then modify the config file which will be read by rectx during building and running do customise how they want rectx to perform certain tasks.

An example of how the config file could look:

[project]
# For storing project information
name = "example-project"
version = "0.1.0"
authors = ["user"]
remote = "github.com/user/example-project"

[profile.build]
# For storing build information (for rectx build)
compiler = "rgoc"
compiler.flags = ["-xx", "-O2"]
output.name = "program"
output.dir = "target/"
source.dir = "src/"
source.main = "main.rct"

[profile.run]
# For storing run information (for rectx run)
compiler = "rctc"
compiler.flags = ["--example-flag"]
output.name = "program"
output.dir = "target/"
source.dir = "src/"
source.main = "main.rct"

Benefits of a config.toml file

This would allow for a lot of customisation on how ReCT programmers would like their programs to compile/run. This also keeps everything in one place and could be committed to repositories allowing for easy compilation by collaborators (instead of having to explain how to compile, people will be able to just do rectx build!).

A config file also has wide-scale expand-ability! It would be very easy to add a new benchmark profile or custom profiles with something like rectx run custom-profile-name (this of course being a completely custom way for the user build/run their programs). Not to mention the example provided above is only an example of what could be possible, more fields and options could definitely be added.

Is your feature request related to a problem? Please describe.
Rust's cargo run has the same feature I think it would be great if rectx could also do that. The solution would prevent occurrances where the user updates the source code but uses rectx run and the same output is generated prior to the updated source code. Essentially, this feature means user won't have to type rectx build && rectx run just rectx run.

Describe the solution you'd like
Store a copy of the source code along side the project files (likely in a .rectx folder) which can then be used for the comparison.

The copy is only made after the first rectx build or rectx run, and future rectx run calls after that will compare the source code to the code. If the source code is the same then rectx will just run the executable found in the build directory and update the copy. Otherwise it will rebuild the project, update the copy, and then run the executable.

The copy of the source will be hashed to save space on the user's disk. Settings in the ~/.rectx/config will be able to be changed to disable hashing (stores the literal code instead).

Additional context
Thank you @RedCubeDev-ByteSpace and @Khhs167 for helping come up with this solution.

Describe the issue
So, rectx build was updated to read data from the project.rectx config file instead of just assuming where the executable is. However, this causes issues if the build/source/main/executable fields in the config are not set. If the fields are not set, then build/run does not know where anything is and just decides to crash.

To Reproduce (only necessary for code)
Steps to reproduce the behavior described above:

1. Step 1
2. Step 2
3. Step 3
4. Outcome

Expected behavior
Project config needs to be filled automatically or build needs to search for the correct folders.

Screenshots

ReCTx's own config file?!

I would like ReCTx to remember some information about the user, the projects the user is developing, as well as information that may be useful to store. In order to do this, rectx will have to have it's own config file to manage. This will probably done within a new module called internal as I would like to keep user config logic separate from rectx config logic.

Where to store?

On Linux/FreeBSD/, the ReCTx config file will be stored in ~/.config/rectx/rectx.toml.
On Windows, it will be stored in %appdata%/rectx/rectx.toml.
And on MacOS, it will be stored in ~/Library/Preferences/rectx/rectx.toml.

What to store?

• User's name
• A list of rectx projects
• Which compilers are installed

Describe the issue
When running rectx template add <file> if the file does not exist, rectx will respond with an error about the file not being a .rectx.template. Additional logic need to be added so it checks if the file exists and if not a better error message is sent.

Screenshots
File "x" does not exist, but the error message assumes it exists.

The project manager is the core feature that will be utilised by the end user. This is because this package handles compilation and project generation. It will also use other modules such as templates, config, and utilities.

Project Manager features

• Handles new prompt
• Uses templates + config modules to generate projects
• Generates project.rectx (config sub-package?)
• Builds the project with build handler
• Runs the project with run handler
• Run/build will read profiles from project.rectx before executing

Todo

• Create project_manager package.
• Create front.go for new, build, and run.
• Create config sub-package for handling project.rectx files.
• Create config structure
• Set up load/dump for config
• Set up config generation (built-in)
• Create prompt for new
• Read selected template
• Generate project structure
• Set up build the executable
• Set up running (simple mode: only run the pre-generated executable or generate if it doesn't exist)

Notable changes

• Move the var block and initFlags() into it's own file (cli.go)
• Finish adding all the commands/subcommands/flags to initFlags()
• Add initFlags to main.go
• Handle subcommands for certain commands
• Add function calls from the appropriate packages

Describe the issue
When a non-default template is chosen (such as short, short_with_build, ...etc) a fatal error occurs stating that main.rct failed to generate.

To Reproduce (only necessary for code)
Steps to reproduce the behavior described above:

1. Create a new project with rectx new
2. Fill in prompt as normal
3. Chose a template short (or short_with_build)
4. Fatal error will appear in console

Expected behavior
Instead of producing an error, the project should generate as normal with the non-default template.

Screenshots
Error message shown as non-default template is chosen:

Additional context
System information:

Is your feature request related to a problem? Please describe.
The config command is used to manage the rectx config (~/rectx/*). This allows the user to change values in the config easily, and potentially recover parts (if not all) of the config.

The config command can be separated into two sections: validate/regenerate for validating and regenerating config files that may have been lost or removed, and reset/set which is used to set values in the config.

Current error handling problem

Current error handling has been minimal as the project is in early development.
Right now, errors are just printed to the user which isn't very user friendly as many of these messages are hard to read, or aren't understandable to people know aren't knowledgeable on Rust.

Solution

To make errors better, the CLI should support a function that can send errors to the user, then each module can report errors through the CLI.
Error handling should match on different error to detect what type of errors have occurred and relay why to the user.
Error messages should convey the actual error at hand (PermissionError, FileNotFound, etc) and then suggest a reason why (assumptions can be made for this).

Error tags

I suggest three error tags: ERROR, ISSUE, ABORT. Each of these has varying serverity: ISSUE; for small issues that the program should be able to recover from, ERROR; when something does not go right and may or may not be recoverable, ABORT; when an issue isn't recoverable and the program is going to exit.

Example:

[ISSUE] A FileNotFoundError occurred in the Config module, maybe a "config.toml" does not exist?

Is your feature request related to a problem? Please describe.
Frequently having to test commands/subcommands and debug issues.
If there is an issue with commands/subcommands/flags then I have to manually go into the code and check what is and is not working.
This is quite inefficient and it would be better to have unit tests that can not only test specific commands, but also test specific functions.
Now, this would be a major time sink because unit tests for each function is a lot of extra code.
However, I think it would be more efficient in the long term, not to mention a lot easier to find where issues in code are coming from.
With testing added there could also be a GitHub workflow added run tests before a pull request can be merged into master.
This would guarantee master is always functional.

Describe the solution you'd like

1. Use Go's testing library to add Unit tests to the code.
2. Set up GitHub Go workflow for testing (go test) for pull requests.

Describe alternatives you've considered
Testing manually is the current solution but is inefficient.

Roadmap

I'd like to have a plan for how I'm going to approach different features I think ReCTx is going to have. Each set of features has a version milestone.

Version & features

v1.0.0

• Custom CLI error reporting
  • Check errors and report to user the issue instead of just printing the rust error message
  • Add ISSUE and ABORT CLI tags (v3.0.0 features early)
• Config file
  • Project information (author, version, binary/library, etc)
  • Building information (compiler, directory, flags, etc)
  • Profiles (release, debug, benchmark, etc)
• #8
• #14

v2.0.0

• Automatically select different compilers when creating a new project
  • Check whether rgoc or rctc is installed and chooses between them
  • Ask user for config value like author, project name, project type, versioning, etc
• Initialise Git repository
• Added .gitignore
• Ask user for what LICENSE they would like
• Fancy CLI changes
  • Add colour to output
  • Special tags for Info, Process, Issue, Abort, etc
  • Progress bars 😎

v3.0.0

• Project templates
  • Customise directories
  • Customise build profiles
  • New projects can be built with the template
• Support for ReCT C libraries
  • Custom project template
  • Build profiles for C
  • Building libraries for ReCT
  • Packaging libraries for RPS

v4.0.0

• Check if packages used in ReCT files are locally installed

This sub-module will manage the project.rectx file. Since this is a part of the project manager package it will be a part of the major project management update.

Features

• Config toml load/dump
• Config file structure
  • Project information
  • Build/run profiles
• Set functions for reading build/run profiles (should make other pieces of code easier to read).

New help menu

Current help menu is a bit tacky, I think it would be better if the help menu looked closer to rgoc's help menu. An example (NOT FINAL) is shown below.

---------------------
ReCTx Project Manager
--------Help---------
Usage: rectx <command>
Commands:
    help    | Shows this help message
    new     | Creates a new project
    build   | Builds the current project
    run     | Runs the current project

For more information check the GitHub page: <link>
Or join the Discord: <link>

Sub-menus

Every command should have a help menu as well, for example rectx help run or rectx help new which says more information about the command.

Colours

Use the colored cargo package to add colour to the help menu.

Describe the issue
During a template snapshot (rectx template snapshot), commands will be collected from a file named "commands". However, the current function searches for files named "commands" with any file extension. This could raise issues with files from other project/build tools or even the project's (user) files itself (e.g. commands.rct would cause issues with the snapshot).

To Reproduce (only necessary for code)
Steps to reproduce the behaviour described above:

1. Create a directory for the snapshot
2. Create a file in the snapshot directory called "commands.rct"
3. Write some basic ReCT code in the "commands.rct" file.
4. Outcome: rectx template snapshot will exit with a fatal error (as of better-errors, otherwise it will produce a Go error).

Expected behavior
Ideally, only certain file extensions should be searched (.txt, <none>, and .rectx perhaps?).

There are labels from <2.0.0 that need to be removed.
Some labels need to be coloured to help differentiate between others of the same colour (auto labeler moment).

Is your feature request related to a problem? Please describe.
Currently a lot of code is still in development so use of utilities.Check(err error) has been widespread. However, this is a simple log.Fatal error checker that results in a crash if something unexpected occurs. As we get closer to the v2.0.0 milestone these errors need to be swapped out for more appropriate errors.

Describe the solution you'd like
This is mostly a simple refactor so it's probably going to be on the back-burner for a while. Here's a list of the modules that use utilities.Check(err error):

• config
• project_manager
• project_manager.config
• templates
• utilities

Additional context

Is your feature request related to a problem? Please describe.
The current template system is in still in development, but for the purposes of getting a fully-working product some features of the system are going to be neglected. This issue is going to highlight the features that still need adding so I don't forgot ;).

Describe the solution you'd like
Here's a list of the features:

• #50
• rectx template test sub-command for testing custom templates. Should parse and generate the template file in a temporary directory. Errors will be printed to stdout so template creators know where issues in their templates are.
• Template binder to check if a folder has been created prior to a file or folder being placed within it. This just involves going through the parsed statements and keeping track of what's been generated and what hasn't.
• Meta-variable parsing with file content during project generation.
• #51
• #53
• Add rectx template rename <name> <newname>: renames a template. Pretty straight forward tbh.
• Add rectx template setDefault <name>
  : set a different template to be the default template generated.
• Add rectx template test <path>: this will test the template by using it to generate a project structure in a temporary directory. This command will search all templates in templates/ before searching by path. This allows users to test if an installed template is working.
• Add rectx template snapshot <path>: When provided the path to a folder, this command will walk through everything in the folder and generate a .rectx.template file that can be edited. This is a fast way of creating templates as the user simply creates the template structure with files/folders and rectx does the heavy lifting.
• Add rectx template add <path>: Adds a template to the template/ directory.

Additional context
Original template pull request: #40

Is your feature request related to a problem? Please describe.
LICENSE generation was an original aim for ReCTx version 2.0.0.

Describe the solution you'd like
The solution is fairly simple, the user will be able to select any license available through rectx (or simple choose to not generate any license), then during project generation, a LICENSE file will be generated.

Is your feature request related to a problem? Please describe.
This isn't technically a feature of rectx, but more a feature of the project overall. I would like the project to be easy to install from various different sources.

Describe the solution you'd like
Below is a list of places rectx could be installed:

• Arch User Repository
• Bash install script (similar to SpaceVim's install script if possible)

Dear Remy.

I can see that you only have support with UNIX-like systems. One good idea is to use cross-platform support from the start. I have seen lines of codes such as:

https://github.com/hrszpuk/rectx/blob/master/src/manager.rs#L82-L84

that won't work in a Windows Operating System (Since they use the Inteligent\Path\main.rct). One option is to use the rust's built-in function std::path::join function.

here are some examples: https://stackoverflow.com/questions/67816016/how-to-get-path-join-in-rust

Have a good day 👍🏽

Enhancements

1. rectx new "name" should detect which compiler is installed (if any) and then generate a config file with the correct compiler set as default. This should save time for the user as they won't have to edit the config file, it should just work out of the box. If both compilers are installed, default to "rgoc", and if no compiler is installed, tell the user how to install them.
2. Instead of rectx new "name", the new command will be rectx new after which the user is asked questions for information such as project name, author name, project type, etc..

Specifics

For number 2, most information should be gathered within the cli module which then passes the information to the manager module later. This keeps everything organized (i.e. input/output is handled by cli).