ethereum / moon-lang

Minimal code-interchange format
MIT License
193 stars 20 forks source link

Updating dependencies with IPFS. #28

Closed Kesanov closed 7 years ago

Kesanov commented 7 years ago

I have few problems with current package system. Listing from most important to the least:

1) It really makes testing your code inconvenient because

2) One file changes, everything changes

3) The hash is opaque.

Kesanov commented 7 years ago

Isn't possible to hash the whole directory? It would make things so much easier.

Moon could then simply access all .moon files in current directory and its subdirectories with ./foo/bar/baz syntax:

base
  |- result
      |- failure.moon
      |- success.moon
  |- maybe
      |- dependencies
          |- result.moon
      |- some.moon
      |- none.moon
      |- toResult.moon
      |- map.moon

base/maybe/dependencies/result.moon


zb2rhWevr8r6R66PNjESCuhiL9dkKUZKT8yMeCU2D97NoH5zC

-- or even better zb2rhWevr8r6R66PNjESCuhiL9dkKUZKT8yMeCU2D97NoH5zC/1.0.1/ -- but that would probably require moon update command


> base/maybe/map.moon

```haskell

some = ./some -- it is possible to access only files ending with .moon (to protect privacy)
none = ./none

fun => maybe =>
  (maybe
    none
    x => (some (fun x)))

base/maybe/toResult.moon

failure = ./dependencies/result/failure
success = ./dependencies/result/success

msg => maybe =>
  (maybe
    (failure msg) -- note that `../result/failure` will not work (to protect privacy)
    x => (success x))
VictorTaelin commented 7 years ago

moon save requires internet connection.

There should be a save --offline option.

moon run requires internet connection 90% of time

Something saved with --offline should be loadable without internet.

You have to run the command each time you change something.

Sorry?

You will often publish a code to IPFS just to realize, your code does not work.

Same way you save a JS file just to notice it doesn't work. (With --offline no IPFS would be involved.)

One file modification requires manual update of its hash in every other file in your package.

  1. Not true. Only files that indirectly include your file, i.e., expectedly log2(N) where N is the amount of files you have.

  2. moon rename path old_hash new_hash should recursively replace all occurrences of old_hash by new_hash in your files. Since those are hashes, this is practical and conflict-free.

  3. This is exactly how it should be. Files that need to be the change are precisely the files that will have their behaviors changed. Moon provides the strong guarantee that a file's behavior will never change if its contents do not change (which I'm not giving up).

Every file modification bumps the version of your package.

Which is what I want (see above).

Git diffs are going to be crazy.

How so?

How am I supposed to know to which version of List this hash zb2rhWevr8r6R66PNjESCuhiL9dkKUZKT8yMeCU2D97NoH5zC points to ? ( The answer is none, it points to Maybe.moon ).

By resolving it?


See, things are done differently and I believe your rejection is mostly for a combination of a lack of tooling, and it being something new. Most of your concerns are addressed by proper tooling. The Moon browser/IDE will do all of that for you.

VictorTaelin commented 7 years ago

Isn't possible to hash the whole directory? It would make things so much easier.

What you want is just a large file with all the definitions, returning a map of exports.

foo = ...

bar = ...

tic = ...

tac = ...

{
  foo: foo
  bar: bar
  tic: tic
  tac: tac
}

I think introducing the concept of directories will bring added complexity for no added benefit.

some = ./some -- it is possible to access only files ending with .moon (to protect privacy)
none = ./none

fun => maybe =>
  (maybe
    none
    x => (some (fun x)))

This is not good IMO. What happens inside the browser, where there is no filesystem? Note Moon is fully portable and environment-agnostic. If you say this only works on the filesystem, then you're throwing away a great feature of Moon, which is you can copy/paste any file in your filesystem to an editor inside a browser and it works just fine, including all its imports...

VictorTaelin commented 7 years ago

Note that you're currently editing files on the command line of a filesystem, which is definitely not how I see things being done in a future. I agree working with Moon today is painful, but this simplicity opens doors which we will explore very soon to make it much better.

Edit: also,

moon save --rename file

Could intelligently perform moon save file; moon rename . old_hash new_hash.

Edit2: closed accidentally

Kesanov commented 7 years ago

I see it might be not be so horrible as I imagined. Especially if there will be 'moon save --rename' which will do the hash replacement automatically.

    1. 2017 10:06 PM, 10:06 PM, MaiaVictor notifications@github.com napsal/a:

      moon save requires internet connection.

      There should be a save --offline option.

      moon run requires internet connection 90% of time

      Something saved with --offline should be loadable without internet.

      You have to run the command each time you change something.

      Sorry?

      You will often publish a code to IPFS just to realize, your code does not work.

      Same way you save a JS file just to notice it doesn't work. (With --offline no IPFS would be involved.)

      One file modification requires manual update of its hash in every other file in your package.

      1. Not true. Only files that indirectly include your file, i.e., expectedly log2(N) where N is the amount of files you have.

      2. moon rename path old_hash new_hash should recursively replace all occurrences of old_hash by new_hash in your files. Since those are hashes, this is practical and conflict-free.

      3. This is exactly how it should be. Files that need to be the change are precisely the files that will have their behaviors changed. Moon provides the strong guarantee that a file's behavior will never change if its contents do not change (which I'm not giving up).

      Every file modification bumps the version of your package.

      Which is what I want (see above).

      Git diffs are going to be crazy.

      How so?

      How am I supposed to know to which version of List this hash zb2rhWevr8r6R66PNjESCuhiL9dkKUZKT8yMeCU2D97NoH5zC points to ? ( The answer is none, it points to Maybe.moon ).

      By resolving it?


      See, things are done differently and I believe your rejection is mostly for a combination of a lack of tooling, and it being something new. Most of your concerns are addressed by proper tooling. The Moon browser/IDE will do all of that for you.

      -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/MaiaVictor/moon-lang/issues/28#issuecomment-330965397

Kesanov commented 7 years ago

This kinda reminds me of git.

What happens if I have old version of List (say three-saves-behind master) and I want to update it. How do I find out which hash points to the version one-save-behind master?

What if I want to update List dependency globally in all my project, how can I check whether some file isn't still using the old version?

It seems to me moon save --offline should be the default.

VictorTaelin commented 7 years ago

This was annoying me too, so now Moon-tool includes a replace command, which recursively replaces all occurrences of an expression by a string, updating imports accordingly. This is sufficient to do what we want with either:

moon replace file.moon "new_file_contents"

Or:

cp file.moon old_file.moon
<save new version on your editor>
moon save file.moon
moon replace $(moon cid old_file.moon) $(moon cid file.moon)
rm old_file.moon

Here is a VIM function to save a Moon file and update all files that import it:

function! SaveMoon()
    silent !clear
    silent !cp % _old.moon
    silent w!
    silent :!echo "$(moon cid _old.moon) -> $(moon save %) (%)"
    :!moon replace $(moon cid _old.moon) $(moon cid %)
    silent !rm _old.moon
endfunction
VictorTaelin commented 7 years ago

I'm not sure I get the problem. If you always save readjusting imports, you'll never get something "3 versions old". If you save something without readjusting imports, then everything that included the old version will keep including the old version and the new one will be a whole new thing. Right?

About offline as default, I think ideally you'll be running an IPFS node (which can be offline) and point Moon to it. Makes sense?

Here is the relevant commit on moon-tool: https://github.com/MaiaVictor/moon-tool/commit/b834191b1dd68be548f2e4b6411d9912e2454516