mirror of
https://github.com/AleoHQ/leo.git
synced 2024-11-13 08:47:17 +03:00
[RFC] Adjust heading levels according to new template.
This commit is contained in:
parent
43c1b29a52
commit
8d26cc5676
@ -8,7 +8,7 @@ The Aleo Team.
|
||||
|
||||
IMPLEMENTED
|
||||
|
||||
# Summary
|
||||
## Summary
|
||||
|
||||
This proposal aims to improve the import management system in Leo programs to
|
||||
make program environment more reproducible, predictable and compatible. To achieve
|
||||
@ -20,7 +20,7 @@ that we suggest few changes to Leo CLI and Manifest:
|
||||
- add "include" and "exclude" parameters for "proving system" and "curve";
|
||||
- add a lock file which would store imported dependencies and their relations;
|
||||
|
||||
# Motivation
|
||||
## Motivation
|
||||
|
||||
The current design of imports does not provide any guarantees on what's stored
|
||||
in program imports and published with the program to Aleo Package Manager.
|
||||
@ -37,9 +37,9 @@ for different proving systems or curves. To make a foundation for these features
|
||||
imports need to be managed with include/exclude lists for allowed (compatible)
|
||||
proving systems and curves.
|
||||
|
||||
# Design
|
||||
## Design
|
||||
|
||||
## Leo Manifest - target section
|
||||
### Leo Manifest - target section
|
||||
|
||||
To lay the foundation for the future of the Leo ecosystem and start integrating
|
||||
information about programs compatibility we suggest adding two new fields to
|
||||
@ -64,7 +64,7 @@ These fields are meant to be used to determine whether imported program is
|
||||
compatible to the original when support for different curves and proving systems
|
||||
is added.
|
||||
|
||||
## Leo Manifest - dependencies
|
||||
### Leo Manifest - dependencies
|
||||
|
||||
Dependencies section:
|
||||
|
||||
@ -79,7 +79,7 @@ package = "package"
|
||||
version = "1.0"
|
||||
```
|
||||
|
||||
### Parameters description
|
||||
#### Parameters description
|
||||
|
||||
`name` field sets the name of the dependency in Leo code. That way we allow
|
||||
developer to resolve collisions in import names manually. So, for example,
|
||||
@ -94,7 +94,7 @@ import sudoku;
|
||||
version respectively. They are already used as arguments in `leo add`
|
||||
command, so these fields are already understood by the Leo developers.
|
||||
|
||||
## Leo CLI
|
||||
### Leo CLI
|
||||
|
||||
To support updated Manifest new command should be added to Leo CLI.
|
||||
|
||||
@ -103,7 +103,7 @@ To support updated Manifest new command should be added to Leo CLI.
|
||||
leo fetch
|
||||
```
|
||||
|
||||
## Imports Restructurization
|
||||
### Imports Restructurization
|
||||
|
||||
One of the goals of proposed changes is to allow importing packages with the
|
||||
same name but different authors. This has to be solved not only on the
|
||||
@ -141,7 +141,7 @@ first-program => author1-program@0.1.0
|
||||
second-program => author2-program2@1.0.4
|
||||
```
|
||||
|
||||
## Leo.lock
|
||||
### Leo.lock
|
||||
|
||||
For imports map to be generated and read by the Leo binary and then by the Leo compiler,
|
||||
a lock file needs to be created. Lock file should be generated by the `leo fetch` command,
|
||||
@ -179,7 +179,7 @@ passed to the compiler.
|
||||
It is important to note that Leo.lock file is created only when a package has dependencies.
|
||||
For programs with no dependencies, a lock file is not required and not created.
|
||||
|
||||
## Recursive Dependencies
|
||||
### Recursive Dependencies
|
||||
|
||||
This improvement introduces recursive dependencies. To solve this case preemptively
|
||||
Leo CLI needs to check the dependency tree and throw an error when a recursive dependency
|
||||
@ -190,7 +190,7 @@ Later this solution can be improved by building a lock file containing all the
|
||||
information on program dependencies, and the file itself will have enough data
|
||||
to track and prevent recursion.
|
||||
|
||||
# Drawbacks
|
||||
## Drawbacks
|
||||
|
||||
This change might require the update of already published programs on Aleo PM due to
|
||||
Leo Manifest change. However it is possible to implement it in a backward-compatible
|
||||
@ -198,14 +198,14 @@ way.
|
||||
|
||||
It also introduces the danger of having recursive dependencies, this problem is addressed in the Design section above.
|
||||
|
||||
# Effect on Ecosystem
|
||||
## Effect on Ecosystem
|
||||
|
||||
Proposed improvement provides safety inside Leo programs and should not affect
|
||||
ecosystem except for the tools which use Leo directly (such as Aleo Studio).
|
||||
|
||||
It is possible that some of the proposed features will open new features on Aleo PM.
|
||||
|
||||
# Alternatives
|
||||
## Alternatives
|
||||
|
||||
Another approach to the stated cases is to keep everything as we have now but change
|
||||
the way programs are imported and stored and make names unique. Also, current
|
||||
|
Loading…
Reference in New Issue
Block a user