dat automatically finds <dat.json>

[okdistribute]

If I type dat . or dat clone dat.json or dat clone . in a directory that has a dat.json file, it should use the url key in the file. This is nice for github repos so I just add the hash once in the dat.json file and forget about it.

[TimothyStiles]

I was just about to propose this feature before searching previous issues. The doc file publish.md describes this as an implemented feature. However, when I try to run dat clone dat.json or dat clone . I get the error message Could not resolve link.

dat clone <link> still works fine.

The link I've been using to test is: dat://778f8d955175c92e4ced5e4f5563f69bfec0c86cc6f670352c457943666fe639

and the dat.json file is:

{
  "title": "Dat command line demo",
  "description": "A dat to use for dat clone demonstrations.",
  "url": "dat://778f8d955175c92e4ced5e4f5563f69bfec0c86cc6f670352c457943666fe639"
}

Is this feature not currently implemented? If not I'd be happy to do it but since I'm new here help or suggestions would be nice! At first glance I'm thinking that modifying either src/parse-args.js or src/commands/clone.js to include dat.json checking and parsing should do the trick.

[ralphtheninja]

@karissa Is dat clone dat.json already supposed to work? From the docs

You might want to be able to get the collaborative benefits of git along with the benefits of fast data download, versioning, p2p, and deduplication with dat. All you have to do is include the dat.json file in your git repository, and tell people to type dat clone for them to get the latest version of your data. Now, when someone clones your git repository, they can download your data by simply typing dat clone dat.json, and the url in the dat.json will be used to download the dat.

[joehand]

Is this feature not currently implemented? If not I'd be happy to do it but since I'm new here help or suggestions would be nice!

That would be great! It is not implemented right now. I made a test for cloning & syncing from git using the metadata key, but dat.json support would be way better.

At first glance I'm thinking that modifying either src/parse-args.js or src/commands/clone.js to include dat.json checking and parsing should do the trick.

Yea, that looks right. Let's start with modifying commands/clone.js, since I think that is the main use case. I see it working like this:

dat clone <working-directory>

where <working-directory> has a dat.json with a key but no .dat folder yet.

We could also support dat clone ./path/to/dat.json but in that command, it is not clear to me where the dat would go (unless the directory was specified as the last argument, dat clone ./path/to/dat.json ./dir). I assume it would go in the same folder as the dat.json but I think specifying the directory makes that more clear.

It'd be great if you want to PR this @TimothyStiles, we're happy to answer questions or give pointers in our chat: chat.datproject.org (login via IRC or gitter).

[TimothyStiles]

@joehand I've put together a pull request that checks for and parses dat clone . and dat clone path/to/dat.json that I haven't submitted yet.

dat clone . and dat clone dat.json both clone the content of the dat repo directly into the current working directory without a fourth dir argument.

dat clone path/to/dat.json without a dir argument makes a new directory named after the key link which contains the dat repo.

dat clone path/to/dat.json dir works as expected.

I've only tried this with empty directories with a single dat.json file in it. It looks like I should also write something that throws an error if there's already a .dat folder within the target directory. Should I make that as a second pull request or roll that into the one I'm about to make?

Also, I can't key pass clone a null value such as dat clone. I think it has something to do with src/parse-args.js. I tried writing a test using the clone - default ops as a template but I've been running into trouble.

[joehand]

Awesome! That all makes sense I think.

It looks like I should also write something that throws an error if there's already a .dat folder within the target directory. Should I make that as a second pull request or roll that into the one I'm about to make?

That should be handled for you via dat-node's opts.errorIfExists https://github.com/datproject/dat/blob/9a7150a10a7b312d408e2c223608eaea6d21f213/src/commands/clone.js#L97. We turned it off in general (https://github.com/datproject/dat/blob/9a7150a10a7b312d408e2c223608eaea6d21f213/src/commands/clone.js#L66) but may be good to set that to true for this situation.

[TimothyStiles]

Alright. I'll submit a pull request for the dat.json parsing then another for .dat existence.

[TimothyStiles]

It looks like the default behavior for dat clone . when there's already a .dat folder is to listen for updates. I'm just going to leave that be.

[joehand]

It looks like the default behavior for dat clone . when there's already a .dat folder is to listen for updates. I'm just going to leave that be.

Ah ya, I guess that is because of my TODO in the code linked above =).

[TimothyStiles]

@karissa can we close this issue? Feature was added in #847.

[ralphtheninja]

@TimothyStiles A nice feature with github is that you can reference an issue from a PR by doing "Closes #PRID" inside the PR description, so when the PR is merged, the related issue will be automatically closed. Just fyi :)

[joehand]

@karissa can we close this issue? Feature was added in #847.

The shortcut/stateless command doesn't quite work: dat /dir/dat.json shares the folder unless you specify a directory as third arg: dat /dir/dat.json /dir/.

It may make more sense to move the dat.json parsing code to dat-node to get the full support in all commands. But I'm not sure we can do that without moving other things like the link resolving their as well.

Anyways, let's keep this open as a reminder for now =). Thanks!