Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

feat: allow daemon to init and start in a single cmd #2428

Merged
merged 19 commits into from
Sep 25, 2019

Conversation

hugomrdias
Copy link
Member

@hugomrdias hugomrdias commented Sep 5, 2019

This PR aligns ipfs init and ipfs daemon with go-ipfs.

ipfs/kubo#6489

ipfs init changed to accept a file path as an argument

ipfs daemon changed to support --init and --init-config options.

Now we can do ipfs daemon --init --init-config /path/to/custom-config

refs:
ipfs/js-ipfsd-ctl#303

Missed the breaking change in the commit msg...

BREAKING CHANGE: ipfs init first positional argument is a path to a file instead of a JSON string. Although the previous version was completely broken.

@achingbrain
Copy link
Member

It would be nicer if it just init'd the repo if it needed to without having to pass flags or anything else.

The new user experience is:

$ ipfs
/// blah blah blah blah long thing don't make me read
$ ipfs daemon
// NO! ERROR!  Run this other command
$ ipfs init
// THANK YOU HUMAN
$ ipfs daemon
...

@achingbrain
Copy link
Member

What I'm saying is, I think we should just init when required instead of adding more flags like this.

Running ipfs init would then be a no-op, unless maybe we want to let the user re-init, in which case something like ipfs init --force might be appropriate?

@alanshaw
Copy link
Member

alanshaw commented Sep 5, 2019

This is really cool and I'm excited to see the speed increase in our CLI tests.

However, I'm struggling to think of a reason why we wouldn't want ipfs daemon to auto-init if not initialised already. Is it a barrier for new users for no reason? @Stebalien @djdv what do you think?

So, how about: remove --init (just auto initialise) but retain --init-config so that we can still pass config?

@Stebalien
Copy link
Member

However, I'm struggling to think of a reason why we wouldn't want ipfs daemon to auto-init if not initialised already.

I agree it should be initialized by default. However, the one reason not to do this is that the current behavior prevents the daemon from being run against the wrong repo. In my case, I always set an explicit repo with IPFS_PATH. My user's repo contains an api file (for my system-wide daemon) and that's it.

But yeah, there's really no reason to not auto initialize.

@hugomrdias
Copy link
Member Author

Should we get this in as is or change it ?

@achingbrain
Copy link
Member

I think we should change this to initialise by default instead of adding extra flags.

@hugomrdias
Copy link
Member Author

done can we get this merged ?

test/cli/daemon.js Outdated Show resolved Hide resolved
@daviddias daviddias mentioned this pull request Sep 10, 2019
66 tasks
@hugomrdias hugomrdias force-pushed the feat/daemon-start-init branch from 8471234 to 5e39dc7 Compare September 11, 2019 15:02
Also tag last successful build and ensure we do not get stealth multiaddr@v7
@@ -265,4 +282,34 @@ describe('daemon', () => {
expect(err.stdout).to.include(`Node.js version: ${process.versions.node}`)
}
})

it('should init by default if not already', async function () {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this test assert that the daemon auto-initialised it's own repo?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ipfs daemon cmd throws if there is no repo initialised. So if this test passes we should be good.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should also assert that the repo was created after the command has run, otherwise it doesn't actually test anything other than that the daemon process was killed. Check the repo directory exists or something like that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My reasoning is to not over test stuff, here we are testing the daemon command and logic, init was added to that logic but we should only test that it gets ran not that init works correctly we have other tests for that.
This test will fail if init isn't ran or if init fails internally, which is the scope i wanted when i wrote the test.
Makes sense ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess its a bit hidden because init is on by default and if init doesn't work daemon also fails completely but still we have other tests that make sure init creates a repo.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this test doesn't test anything not covered by other tests it should be removed.

If it does test something not covered by other tests, it should contain assertions to prove the functionality being tested works as expected.

Too many of our tests don't actually test anything, they just ensure that nothing on the happy path explodes so aren't all that useful.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@achingbrain is right. Tests should be both valuable and informative. If it requires one to know that the test is testing for the program not to blow up in some weird situation, at least that needs to be well documented and not just live in one persons brain.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the assertion is this if (stdout.includes('Daemon is ready')) { i agree this isn't the best way to do things and i will improve this in a near future, but this is the way we assert a daemon ran successfully in the others tests.

this is the first test to work without calling ipfs(init).

either i remove the test or change the name to something more informative like 'should start the daemon and init automatically without calling init first' or something else but i don't think testing for the repo is useful here.
im open to suggestions

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestions were:

  • Document it with code comments
  • Assert that the repo was created as part of the test

This PR aligns `ipfs init` and `ipfs daemon` with go-ipfs.

ipfs/kubo#6489

`ipfs init` changed to accept a file path as an argument

`ipfs daemon` changed to support `--init` and `--init-config` options.

Now we can do `ipfs daemon --init --init-config /path/to/custom-config`

refs:
ipfs/js-ipfsd-ctl#303
@hugomrdias hugomrdias force-pushed the feat/daemon-start-init branch from 5e39dc7 to d134357 Compare September 16, 2019 11:48
hugomrdias added a commit to ipfs-inactive/interface-js-ipfs-core that referenced this pull request Sep 16, 2019
BREAKING CHANGE: swarm tests need promise based setup check PRs below

the following PRs add support async setup:
ipfs-inactive/js-ipfs-http-client#1105
ipfs/js-ipfs#2428
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants