Get rid of the mock version again in favor of persisting 'next'
This commit is contained in:
Matej Sima
parent
a75b16037f
commit
91c5eb694e
@ -1 +1 @@
|
|||||||
require('./preversion');
|
// require('./preversion');
|
||||||
@ -1,48 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-api-cli-commands
|
|
||||||
title: CLI Commands
|
|
||||||
original_id: api-cli-commands
|
|
||||||
---
|
|
||||||
|
|
||||||
Contracts written in Ligo can be compiled using the `ligo` executable.
|
|
||||||
|
|
||||||
|
|
||||||
## Compiling a contract
|
|
||||||
|
|
||||||
Compile your contract with a specific entry point.
|
|
||||||
|
|
||||||
```zsh
|
|
||||||
ligo compile-contract SOURCE_FILE [ENTRY_POINT]
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Example
|
|
||||||
|
|
||||||
```zsh
|
|
||||||
ligo compile-contract examples/counter.ligo main
|
|
||||||
```
|
|
||||||
|
|
||||||
## Defining the initial storage
|
|
||||||
|
|
||||||
If your contract implements a sophisticated storage, you can compile a Ligo expression into a Michelson value quite easily.
|
|
||||||
|
|
||||||
```zsh
|
|
||||||
ligo compile-storage SOURCE_FILE ENTRY_POINT EXPRESSION
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Example
|
|
||||||
```zsh
|
|
||||||
ligo compile-storage examples/counter.ligo main 5
|
|
||||||
# Outputs: 5
|
|
||||||
```
|
|
||||||
|
|
||||||
## Invoking the contract with a parameter
|
|
||||||
|
|
||||||
```zsh
|
|
||||||
ligo compile-parameter SOURCE_FILE ENTRY_POINT EXPRESSION
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Example
|
|
||||||
```zsh
|
|
||||||
ligo compile-parameter examples/counter.ligo main "Increment(5)"
|
|
||||||
# Outputs: (Right 5)
|
|
||||||
```
|
|
||||||
@ -1,19 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-back-end
|
|
||||||
title: Back End
|
|
||||||
original_id: back-end
|
|
||||||
---
|
|
||||||
|
|
||||||
The Back-End is the part that compiles down to Michelson. Instead of a single compilation step, it is separated in two parts.
|
|
||||||
## Transpiler and Mini_C
|
|
||||||
The Transpiler is a function that takes as input the Typed AST, and outputs expressions in a language that is basically a Michelson based on with named variables and first-class-environments.
|
|
||||||
On the one hand, there are cases in the AST like `E_if_bool` or `E_make_empty_list` that would be directly translated in Michelson like `IF {} {}` or `NIL`.
|
|
||||||
On the other hand, there are cases in the AST like `E_variable` or `E_environment_select` that specifically target the compiler.
|
|
||||||
The files of the Transpiler are in `transpiler/`, while those of Mini_c are in `mini_c/`.
|
|
||||||
## Compiler
|
|
||||||
The previous LIGO’s compilation to Michelson model was quite complicated. The current one is quite straightforward, where the environment of variables (x -> 12, y -> “foo”) is compiled as Michelson stack (12 :: foo).
|
|
||||||
It has been simplified for multiple reasons:
|
|
||||||
Having a simple model reduces its number of points of failure.
|
|
||||||
Having a simple model makes optimizing it easier.
|
|
||||||
We submitted a change to the Tezos’ protocol that actually make it more efficient.
|
|
||||||
|
|
||||||
@ -1,16 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-front-end
|
|
||||||
title: Front End
|
|
||||||
original_id: front-end
|
|
||||||
---
|
|
||||||
|
|
||||||
The Front-End is the part that deals with all syntactical matters. LIGO supports multiple Front-Ends. Each Front-End is composed of three different parts.
|
|
||||||
## Parser
|
|
||||||
A Parser is a function that takes a string of source code and outputs a structured representation of the program. This part usually uses Menhir, a parser generator compatible with OCaml.
|
|
||||||
Its files are in `parser/parser_name`.
|
|
||||||
## Concrete Syntax Tree
|
|
||||||
The CST is the aforementioned structured representation of the program. Is is structurally very close to the source code, and is mostly an intermediary there because manipulating string is not practical.
|
|
||||||
Its files are in `parser/parser_name`.
|
|
||||||
## Simplifier
|
|
||||||
A Simplifier is a function that takes a CST and outputs the corresponding Common AST. This is the actual bridge between a given syntax and LIGO.
|
|
||||||
Its files are in `simplify/parser_name`.
|
|
||||||
@ -1,17 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-middle-end
|
|
||||||
title: Middle End
|
|
||||||
original_id: middle-end
|
|
||||||
---
|
|
||||||
|
|
||||||
The Middle-End is the core of LIGO. It is also composed of three parts.
|
|
||||||
## Common AST
|
|
||||||
The Common AST is the closest thing to what could be called “LIGO lang”. As such, it should be as simple as possible. Collapsing particular cases in more general constructs is encouraged. Documenting it is crucial for people who’ll write new parsers or editor support for Front-end related things.
|
|
||||||
Its files are in `ast_simplified/`, of interest is the definition of the AST itself in `ast_simplified/types.ml`.
|
|
||||||
## Type Checker
|
|
||||||
The Type Checker, among other things, checks that a given AST is valid with regard to type-safety. It also annotates expressions with their types, free-variables and local environments.
|
|
||||||
As time passes, we want to make the type-system stronger, to encode arbitrarily complex properties in an extensible manner.
|
|
||||||
Its files are in `typer/`.
|
|
||||||
## Typed AST
|
|
||||||
The Typed AST is the result of Type Checker. On top of it, we also want to define/export many features aiming at making building tools on top LIGO as easy as possible.
|
|
||||||
Its files are in `ast_typed/`, of interest is the definition of the Typed AST itself in `ast_typed/types.ml`.
|
|
||||||
@ -1,17 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-overview
|
|
||||||
title: Overview
|
|
||||||
original_id: overview
|
|
||||||
---
|
|
||||||
|
|
||||||
After going through the design principles and a few considerations linked to them, getting the Big Picture needs diving in technical matters.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
As shown in the Schema, LIGO’s compiler is separated in roughly 3 separate parts:
|
|
||||||
|
|
||||||
- The Middle End. This is the core of LIGO. It defines its core data-structure (the Common AST), and its type-checking algorithm.
|
|
||||||
|
|
||||||
- The Front End. This is the bridge between a given syntax and the Common AST.
|
|
||||||
|
|
||||||
- The Back End. This is the bridge between the Common AST and a given compilation target. Currently, our only target is Michelson, but we’ll also target Marigold, and if Tezos moves to Web Assembly, Web Assembly.
|
|
||||||
@ -1,22 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-vendors
|
|
||||||
title: Vendors
|
|
||||||
original_id: vendors
|
|
||||||
---
|
|
||||||
|
|
||||||
Next to LIGO’s main pipeline, we use some other libraries, that are in the folder `vendors`.
|
|
||||||
## ligo-utils
|
|
||||||
This, quite expectedly, defines utilities that are used in LIGO.
|
|
||||||
There are three kinds of utilities, corresponding to their dependencies.
|
|
||||||
|
|
||||||
`tezos-utils` contain utilities that depend on some Tezos libraries.
|
|
||||||
|
|
||||||
`proto-alpha-utils` contain utilities that depend on the compilation of some Tezos protocol. It is very big and thus can’t be compiled in JS. This is because of a dependency to this that we don’t have LIGO in the browser yet.
|
|
||||||
|
|
||||||
`simple-utils` contain most utilities. For instance, in `simple-utils` are `X_list` and `X_option`, that extend the `List` module and the `option` type found in `Pervasives`.
|
|
||||||
|
|
||||||
Of particular interest in `simple-utils` is `trace.ml`, a module used pervasively in LIGO’s code-base. It deals with exceptions (and soon enough debugging annotations) in a functional manner. It offers a lot of utilities to build, combine and propagate exceptions. Given it’s used everywhere, that it relies on some advanced features of OCaml (higher order functions, ppx preprocessing) and that it exposes **a lot** of functions, it’s a good idea to look at this file’s documentation.
|
|
||||||
## tezos-modded
|
|
||||||
`tezos-modded` is a modded version of Tezos. There are modifications in it that are quite useful (exposing more functions from the protocol, giving more options to functions already defined), but not integrated yet.
|
|
||||||
It should in the end be integrated into the Tezos protocol, but until then, we use this.
|
|
||||||
|
|
||||||
@ -1,21 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-documentation-and-releases
|
|
||||||
title: Documentation and releases
|
|
||||||
original_id: documentation-and-releases
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
## Documentation
|
|
||||||
|
|
||||||
In case you'd like to contribute to the docs, you can find them at [`gitlab-pages/docs`]() in their raw markdown form.
|
|
||||||
Deployment of the docs/website for LIGO is taken care of within the CI, from `dev` and `master` branches.
|
|
||||||
|
|
||||||
## Releases & versioning
|
|
||||||
|
|
||||||
### Development releases (next)
|
|
||||||
|
|
||||||
Development releases of Ligo are tagged as `next` and are built with each commit to the `dev` branch. Both the docker image & the website are published automatically.
|
|
||||||
|
|
||||||
### Stable releases
|
|
||||||
|
|
||||||
Releases tagged with version numbers `x.x.x` are built manually, both docs & the docker image. While deployment of the website is handled by the CI.
|
|
||||||
@ -1,41 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-getting-started
|
|
||||||
title: Getting started
|
|
||||||
original_id: getting-started
|
|
||||||
---
|
|
||||||
|
|
||||||
## Where
|
|
||||||
As we’ve seen, LIGO is big, as such, it is easier to start focus on a specific part of LIGO. As very vague suggestions:
|
|
||||||
If you want to immediately see the result of your contributions, you might want to start with the Front-End. This is what most people will directly see of LIGO.
|
|
||||||
If you want to get into Programming Language Theory, you might want to start with the Middle-End. This is where the Type System and the Language Definition are (the closest thing so far that you’ll find in a research paper).
|
|
||||||
If you want to get into the nitty gritty details of compiling to special targets, you’ll want to focus on the Back-End.
|
|
||||||
If you want to develop tooling on top of LIGO (editor integration, for instance), you’ll want to look at `Ast_typed/types.ml`. This is where most information that is relevant to devs will be (for now).
|
|
||||||
If you really want to get a grasp of the whole pipeline, search for issues tagged with “Everything”, they’ll have you look at multiple parts of the code base.
|
|
||||||
## What
|
|
||||||
Likely, the first issues will be about:
|
|
||||||
Adding tests
|
|
||||||
Extending the languages by adding new operators
|
|
||||||
Adding tests
|
|
||||||
Refactoring
|
|
||||||
Writing documentation and tutorials for users
|
|
||||||
Adding tests
|
|
||||||
Writing internal documentation when you understand a part of the code base
|
|
||||||
>Tests are **really** important, we don’t have lots of them, and mostly regression ones. This can’t be stressed enough. Some features are missing not because we can’t add them, but because we don’t know so as no tests tell us they are missing.
|
|
||||||
## How
|
|
||||||
Issues will be added to the Gitlab, tagged with On-boarding and Front-End / Middle-End / Back-End / Everything. If you try to tackle one issue, and you have **any** problem, please tell us, by creating a new Gitlab issue, contacting us on Riot, Discord or even by mail! Problems might include:
|
|
||||||
Installing the repository or the tools needed to work on it
|
|
||||||
OCaml weirdness
|
|
||||||
Understanding undocumented parts of the code base
|
|
||||||
Documented parts of the code base too
|
|
||||||
**Anything really**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## FAQ
|
|
||||||
### I don’t know much about OCaml, where should I start? What should I have in mind?
|
|
||||||
I’d suggesting going through Real World OCaml to get a feel for the language, to know what are its features, and to know what to Google when you’re lost.
|
|
||||||
Beyond that, I’d say, start hacking! Either on LIGO’s code base, or on any personal project.
|
|
||||||
There is a Discord server if you want real-time help (which makes things go way faster than waiting for an answer on stackoverflow or looking mindlessly at the monitor).
|
|
||||||
### I want to add [X] to LIGO! Where should I begin?
|
|
||||||
Trying to add a new feature from scratch instead of building upon one can be quite complicated. However, if you’re motivated, contact us! We’ll tell you what we see as the most likely plan to get the result you want to achieve.
|
|
||||||
|
|
||||||
@ -1,11 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-origin
|
|
||||||
title: Origin
|
|
||||||
original_id: origin
|
|
||||||
---
|
|
||||||
|
|
||||||
LIGO is a programming language that aims to provide developers with an uncomplicated and safer way to implement smart-contracts. LIGO is currently being implemented for the Tezos blockchain and as a result, it compiles down to Michelson - the native smart-contract language of Tezos.
|
|
||||||
|
|
||||||
> Smart-contracts are programs that run within a blockchain network.
|
|
||||||
|
|
||||||
LIGO was initially meant to be a language for developing Marigold, on top of a hacky framework called Meta-Michelson. However, due to the attention received by the Tezos community, a decision has been put into action to develop LIGO as a standalone language that will support Tezos directly as well.
|
|
||||||
@ -1,46 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-philosophy
|
|
||||||
title: Philosophy
|
|
||||||
original_id: philosophy
|
|
||||||
---
|
|
||||||
|
|
||||||
To understand LIGO’s design choices, it’s important to get its philosophy. There are two main concerns that we have in mind when building LIGO.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Safety
|
|
||||||
Once a smart-contract is deployed, it will likely be impossible to change it. You must get it right on the first try, and LIGO should help as much as possible. There are multiple ways to make LIGO a safer language for smart-contracts.
|
|
||||||
|
|
||||||
### Automated Testing
|
|
||||||
Automated Testing is the process through which a program will run some other program, and check that this other program behaves correctly.
|
|
||||||
There already is a testing library for LIGO programs written in OCaml that is used to test LIGO itself. Making it accessible to users will greatly improve safety. A way to do so would be to make it accessible from within LIGO.
|
|
||||||
|
|
||||||
### Static Analysis
|
|
||||||
Static analysis is the process of having a program analyze another one.
|
|
||||||
For instance, type systems are a kind of static analysis through which it is possible to find lots of bugs. There is already a fairly simple type system in LIGO, and we plan to make it much stronger.
|
|
||||||
|
|
||||||
### Conciseness
|
|
||||||
Writing less code gives you less room to introduce errors and that's why LIGO encourages writing lean rather than chunky smart-contracts.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Ergonomics
|
|
||||||
Having an ergonomic product is crucial on multiple levels:
|
|
||||||
Making features easily accessible ensures they’ll actually get used.
|
|
||||||
Not wasting users time on idiosyncrasies frees more time for making contracts safer or building apps.
|
|
||||||
Keeping users in a Flow state makes it possible to introduce more complex features in the language.
|
|
||||||
There are multiple ways to improve ergonomics.
|
|
||||||
|
|
||||||
### The Language
|
|
||||||
LIGO should contain as few surprises as possible. This is usually known as the principle of least surprise.
|
|
||||||
|
|
||||||
Most programmers who will use LIGO have already spent a lot of time learning to develop in an existing language, with its own set of conventions and expectations. These expectations are often the most important to accommodate. This is why C-style syntaxes are especially popular (e.g. JavaScript), C-style is well known and new languages want to take advantage of that familiarity. Therefore as an extension of the principle of least surprise, LIGO supports more than one syntax. The least surprising language for a new developer is the one that they have already learned how to use. It’s probably not practical to replicate the syntax of every programming language, so LIGO takes the approach of replicating the structure used by languages from a particular paradigm.
|
|
||||||
|
|
||||||
It is packaged in a Docker container, so that no particular installation instructions are required.
|
|
||||||
|
|
||||||
### Editor Support
|
|
||||||
Without editor support, a lot of manipulations are very cumbersome. Checking for errors, testing, examining code, refactoring code, etc. This is why there is ongoing work on editor support, starting with highlighting and code-folding.
|
|
||||||
|
|
||||||
### Docs
|
|
||||||
Docs include documentation of the languages, tutorials, as well as examples and design patterns.
|
|
||||||
We’re a long way from there. But having extensive docs is part of our goals.
|
|
||||||
@ -1,21 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-long-term
|
|
||||||
title: Longer term
|
|
||||||
original_id: long-term
|
|
||||||
---
|
|
||||||
|
|
||||||
Soon enough, the Schema for the front-end will look like this:
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Basically, as we support more syntaxes (up to half a dozen), we’ll have a bigger need for a unified representation and generation of the helpers around it.
|
|
||||||
For instance:
|
|
||||||
Parsers. So far, parsers are generated by LR grammars. LR grammars have a steep learning curve, regularly making not worth it for someone to learn the whole formalism to extend a given grammar with a few cases. Generating those LR Grammars would thus save a lot of time.
|
|
||||||
Displayers. The idea is that if you can parse and display code in a given syntax, it becomes much easier to have a translator between each syntax. So that not only it becomes possible for users to write code in their favorite syntax, but also to only read code in their favorite syntax.
|
|
||||||
BNFs. BNF grammars are a common formalism to represent grammars. They are understood by many tools, and are an easy way to document a given syntax.
|
|
||||||
## Super Type System
|
|
||||||
Soon enough, the Schema for the middle-end will look like this:
|
|
||||||
|
|
||||||
Basically, this schema shows that the Back-End will stop being the main consumer of the Typed AST, and the External World will in its stead.
|
|
||||||
As such, annotating the AST with quality information, documenting it and exposing the libraries that produced the information in the first place will be paramount.
|
|
||||||
The imagined type-system so far is a mixture of MLF, extensible data-types and Algebraic Effects.
|
|
||||||
@ -1,21 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-short-term
|
|
||||||
title: Short term
|
|
||||||
original_id: short-term
|
|
||||||
---
|
|
||||||
|
|
||||||
## Documentation and Testing
|
|
||||||
We lack documentation and tests. Top priority.
|
|
||||||
Tests are needed at multiple levels:
|
|
||||||
Unit tests. Most utility functions should be tested individually.
|
|
||||||
Interface tests. Parts of the pipeline (Typer, Transpiler-Compiler, etc.) should be tested as black boxes.
|
|
||||||
Integration tests. Typical user scenarios, as interacted with the CLI, should be tested.
|
|
||||||
## Exposing Features
|
|
||||||
Many features have already been developed or nearly developed, and mostly need to be shown some attention, and then be exposed to the outside world, for instance:
|
|
||||||
Testing LIGO code
|
|
||||||
Step-by-step interpreter
|
|
||||||
LIGO in the browser
|
|
||||||
Propagating source locations for error messages
|
|
||||||
Dry-running a contract
|
|
||||||
## Refactoring
|
|
||||||
For the longer-term, it’s crucial to refactor big parts of the code base. This is needed to lower the complexity of the code base, so that it’s easier both for everyone (including API consumers) to interact with it.
|
|
||||||
@ -1,45 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-language-basics-entrypoints
|
|
||||||
title: Entrypoints
|
|
||||||
original_id: language-basics-entrypoints
|
|
||||||
---
|
|
||||||
|
|
||||||
## Defining an entry point
|
|
||||||
|
|
||||||
<!--DOCUSAURUS_CODE_TABS-->
|
|
||||||
<!--Pascaligo-->
|
|
||||||
```Pascal
|
|
||||||
function main (const p : int ; const s : int) : (list(operation) * unit) is
|
|
||||||
block {skip} with ((nil : list(operation)), s + 1)
|
|
||||||
```
|
|
||||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
|
||||||
|
|
||||||
## Multiple entry points
|
|
||||||
|
|
||||||
Multiple entrypoints are currently not supported in Michelson, however with Ligo, you can work that around by using variants.
|
|
||||||
|
|
||||||
<!--DOCUSAURUS_CODE_TABS-->
|
|
||||||
<!--Pascaligo-->
|
|
||||||
```Pascal
|
|
||||||
// variant defining pseudo multi-entrypoint actions
|
|
||||||
type action is
|
|
||||||
| Increment of int
|
|
||||||
| Decrement of int
|
|
||||||
|
|
||||||
function add (const a : int ; const b : int) : int is
|
|
||||||
block { skip } with a + b
|
|
||||||
|
|
||||||
function subtract (const a : int ; const b : int) : int is
|
|
||||||
block { skip } with a - b
|
|
||||||
|
|
||||||
// real entrypoint that re-routes the flow based on the action provided
|
|
||||||
function main (const p : action ; const s : int) : (list(operation) * int) is
|
|
||||||
block {skip} with ((nil : list(operation)),
|
|
||||||
case p of
|
|
||||||
| Increment n -> add(s, n)
|
|
||||||
| Decrement n -> subtract(s, n)
|
|
||||||
end)
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
|
||||||
@ -1,23 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-language-basics-functions
|
|
||||||
title: Functions
|
|
||||||
original_id: language-basics-functions
|
|
||||||
---
|
|
||||||
|
|
||||||
## Defining a function
|
|
||||||
|
|
||||||
<!--DOCUSAURUS_CODE_TABS-->
|
|
||||||
<!--Pascaligo-->
|
|
||||||
```Pascal
|
|
||||||
// multiply(1, 2) = 2
|
|
||||||
function multiply (const a : int ; const b : int) : int is
|
|
||||||
begin
|
|
||||||
const result : int = a * b ;
|
|
||||||
end with result
|
|
||||||
|
|
||||||
// add(1, 2) = 3
|
|
||||||
function add (const a : int ; const b : int) : int is
|
|
||||||
block { skip } with a + b
|
|
||||||
```
|
|
||||||
|
|
||||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
|
||||||
@ -1,13 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-language-basics-operators
|
|
||||||
title: Operators
|
|
||||||
original_id: language-basics-operators
|
|
||||||
---
|
|
||||||
|
|
||||||
## Available operators
|
|
||||||
|
|
||||||
|Michelson |Pascaligo |Description |
|
|
||||||
|--- |--- |--- |
|
|
||||||
| `SENDER` | `sender` | Address that initiated the current transaction
|
|
||||||
| `SOURCE` | `source` | Address that initiated the transaction, which triggered the current transaction. (useful e.g. when there's a transaction sent by another contract)
|
|
||||||
| `AMOUNT` | `amount` | Amount of tez sent by the transaction that invoked the contract
|
|
||||||
@ -1,19 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-language-basics-variables
|
|
||||||
title: Variables
|
|
||||||
original_id: language-basics-variables
|
|
||||||
---
|
|
||||||
|
|
||||||
## Defining a variable
|
|
||||||
|
|
||||||
<!--DOCUSAURUS_CODE_TABS-->
|
|
||||||
<!--Pascaligo-->
|
|
||||||
```Pascal
|
|
||||||
// int
|
|
||||||
const four : int = 4;
|
|
||||||
|
|
||||||
// string
|
|
||||||
const name : string = "John Doe";
|
|
||||||
```
|
|
||||||
|
|
||||||
<!--END_DOCUSAURUS_CODE_TABS-->
|
|
||||||
@ -1,39 +0,0 @@
|
|||||||
---
|
|
||||||
id: version-mock-setup-installation
|
|
||||||
title: Installation
|
|
||||||
original_id: setup-installation
|
|
||||||
---
|
|
||||||
|
|
||||||
There are currently two ways to get started with Ligo, both of those will allow you to use the Ligo CLI with your contracts. You can choose to use either the Docker image, or to compile & build the Ligo CLI yourself.
|
|
||||||
|
|
||||||
## Dockerized installation (recommended)
|
|
||||||
|
|
||||||
> 🐳 You can find instructions on how to install Docker [here](https://docs.docker.com/install/).
|
|
||||||
|
|
||||||
Easiest way to use LIGO is through the Docker image available at [Docker Hub](https://hub.docker.com/r/ligolang/ligo). Sources for the image can be found on [Gitlab](https://gitlab.com/ligolang/ligo/blob/master/docker/Dockerfile).
|
|
||||||
You can either run the docker image yourself, or you can setup a global ligo executable as shown below.
|
|
||||||
|
|
||||||
### Setting up a globally available `ligo` executable
|
|
||||||
|
|
||||||
> You can install additional ligo versions by replacing `next` with the required version number
|
|
||||||
|
|
||||||
```zsh
|
|
||||||
# next (pre-release)
|
|
||||||
curl https://gitlab.com/ligolang/ligo/blob/master/scripts/installer.sh | bash "next"
|
|
||||||
|
|
||||||
# e.g. 1.0.0 (stable)
|
|
||||||
curl https://gitlab.com/ligolang/ligo/blob/master/scripts/installer.sh | bash "1.0.0"
|
|
||||||
```
|
|
||||||
|
|
||||||
**Verify your ligo installation by running:**
|
|
||||||
```zsh
|
|
||||||
ligo --help
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|
||||||
## Manual installation (advanced)
|
|
||||||
|
|
||||||
For now, please refer to the steps described in the [Dockerfile](https://gitlab.com/ligolang/ligo/blob/master/docker/Dockerfile).
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -1,35 +0,0 @@
|
|||||||
{
|
|
||||||
"version-mock-docs": {
|
|
||||||
"Setup": [
|
|
||||||
"version-mock-setup-installation"
|
|
||||||
],
|
|
||||||
"Language Basics": [
|
|
||||||
"version-mock-language-basics-variables",
|
|
||||||
"version-mock-language-basics-functions",
|
|
||||||
"version-mock-language-basics-entrypoints",
|
|
||||||
"version-mock-language-basics-operators"
|
|
||||||
],
|
|
||||||
"API": [
|
|
||||||
"version-mock-api-cli-commands"
|
|
||||||
]
|
|
||||||
},
|
|
||||||
"version-mock-contributors-docs": {
|
|
||||||
"Introduction": [
|
|
||||||
"version-mock-contributors/origin",
|
|
||||||
"version-mock-contributors/philosophy",
|
|
||||||
"version-mock-contributors/getting-started",
|
|
||||||
"version-mock-contributors/documentation-and-releases"
|
|
||||||
],
|
|
||||||
"Big Picture": [
|
|
||||||
"version-mock-contributors/big-picture/overview",
|
|
||||||
"version-mock-contributors/big-picture/front-end",
|
|
||||||
"version-mock-contributors/big-picture/middle-end",
|
|
||||||
"version-mock-contributors/big-picture/back-end",
|
|
||||||
"version-mock-contributors/big-picture/vendors"
|
|
||||||
],
|
|
||||||
"Road Map": [
|
|
||||||
"version-mock-contributors/road-map/short-term",
|
|
||||||
"version-mock-contributors/road-map/long-term"
|
|
||||||
]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
@ -1 +1 @@
|
|||||||
["mock"]
|
["next"]
|
||||||
Loading…
Reference in New Issue
Block a user