separate repos for stdlib

[CymDeveloppement]

Maybe it's a good choice to separate stlib into a new repository.
Before starting a new issue in Amber repositories for new features we can try in stdlib.
for example :
color text
sudo execution
debug mode
native lock file
and unit test
I can try to made a repos and include unit test write with Amber

[b1ek]

i agree, that would allow us to have a heavily packed stdlib, since there is no packaging yet.

[b1ek]

related (tests): #222

[Mte90]

I agree but it is something that requires some implementation in amber, like to create new blocks.

Anyway yes it is the best way to move on so can happen independently from the project itself.

[Ph0enixKM]

We can implement a separate versioning of stdlib in the same repository. I dislike the idea to spread everything to separate repositories (at least for now at alpha stage) as everything gets harder to integrate together (it just adds unnecessary additional steps). We can just create a directory stdlib in the root of the project that has it's own tests and everything. And yeah this is another question we have to answer - what testing solution we'll be using to test Amber stdlib if we want to treat it as a separate entity? Some JavaScript library or maybe we could write a testing library in Amber?

[Mte90]

Just imagine people reporting issues or stuff for stdlib every day instead of issues about Amber itself in this Repo.
In this way the mantainer can't focus very good.

[FedericoCeratto]

Splitting stdlib and compiler can make the release process more difficult and add complexity for OS package maintainers. It also makes unit and functional testing of the compiler and the stdlib more difficult, as they need to move in lockstep.
The split could be useful if Amber had multiple compilers implemented by different projects.

[Mte90]

I don't think at all that will add complexity as we are still in alpha.
I mean we can evolve the stdlib outside this Repo with different discussion and during the build process can download the other repository with just the stdlib and unit tests.

When the stdlib is solid we can merge both and remove the other one.

[CymDeveloppement]

I understand, there is a close connection between Amber and the stdlib. Maybe including stdlib in the build process is a good choice.
During my first attempts, it is necessary to carry out tests with Amber to limit the use of Rust.
But #229 stopped me, actually we cannot create a function like this test_amber(my_test_function(), "Hello Amber!").
I think a doc folder with one Markdown file by function is interesting or a standardized comment section can be converted to md file.

[Ph0enixKM]

I partially agree with all of you.

At this early stage, if the standard library does not function as intended, it could be a compiler issue. In such cases, we can re-label the issue instead of recreating it.

I recognize that the root cause is that not everyone understands Rust, and developing tests for the standard library can be challenging. One possible solution is to separate std from the main source (src directory) and provide it with its own README and unit test library written in Amber. This could be an effective compromise and a valuable idea.

I propose keeping everything in a single repository for the reasons stated by @FedericoCeratto, as it would maintain our workflow. Splitting them does not seem to simplify the complexity of this project or add significant value. While it was suggested that separating them could facilitate easier filtering on our GitHub project or issues, there is already a built-in filter for this purpose. Additionally, I have not found any compilers, such as those for Swift, TypeScript, Go, or Rust, that separate the standard library from the project. Overall, keeping everything together seems to be the more practical approach.

[Mte90]

I want to add that is normal that projects like you mentioned have the stdlib in the same project but they are solid and stable.
Right now the Amber language is not yet defined at 100% and also the feature set so they are in a different case. Also they often have a process called RFC (PHP and Python for example) to discuss new stuff that is in a different project.

We have various issues opened about stdlib https://github.com/Ph0enixKM/Amber/issues?q=sort%3Aupdated-desc+is%3Aissue+stdlib+is%3Aopen some for tests and others for new function.
Ideally to discuss everything we should have an issue for every new method so we can discuss easily before to do like I did in a PR #185 with various reviews and new functions added and other removed.

We should discuss before implement and this means that for stdlib we can have tons of discussions but Amber has different priorities right now, like improve the compiler or the language features.

In a different repository in a GH organization we can do that without annoy the people that is working to Amber itself.

Anyway for sure stdlib should be aligned/tested with the latest version of Amber itself and we can do that releasing a new tag with the same version of Amber in that repository.

My only needs for a different repository is not full the inbox with notification that you don't need to follow so the Rust skilled people can work on the compiler without bothering if a function name is better as create_symbolic_link or make_symbolic_link.

In projects like this is easy to be burned out because there are too many things to follow and creating a different project can help gathering more contributors and involve them in the project.
I suggest again create a GH organization and move the repositories there and create that one.

We can discuss in a different issue about how to implement tests if we do that.

I worked in various projects in my life and I think that is the best move and I want to remember that is just temporary.

[Mte90]

We have a ticket for that #330