update link to filestore experimental status #4557
Conversation
According to ipfs#3397 (comment), the status of experimental features is now tracked in a file in the repo, not in an issue. License: MIT Signed-off-by: Leo Arias <[email protected]>
| @@ -195,7 +195,7 @@ You can now check what blocks have been created by: | |||
| hashFunStr, hfset, _ := req.Option(hashOptionName).String() | |||
|
|
|||
| if nocopy && !cfg.Experimental.FilestoreEnabled { | |||
| res.SetError(errors.New("filestore is not enabled, see https://git.io/vy4XN"), | |||
| res.SetError(errors.New("filestore is not enabled, see https://git.io/vNItf"), | |||
| cmdkit.ErrClient) | |||
There was a problem hiding this comment.
I have a personal dislike for the use of short links unless absolutely necessary and would prefer https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#ipfs-filestore is used.
But since a short URL was already used I am not going to block this.
There was a problem hiding this comment.
I think this is because it happens in an error message. Tools have a bad habit of truncating logs/error messages so this is safer...
There was a problem hiding this comment.
How about changing the error to print what the user has to do to enable it + the link to the doc? Something like:
Filestore is not enabled. Run `ipfs config --json Experimental.FilestoreEnabled true` to enable it. See https://git.io/vNItf for more information.
As it stands right now, unless I have internet access, it becomes hard to figure out how to enable it. And if the user is not interested in more info, just to enable the feature, this would make the flow the quickest.
There was a problem hiding this comment.
I'd do that as a separate change. This fixes a specific bug.
(Really, I'd like to ship an immutable datastore with IPFS that includes the docs. Then, we could just tell people to read, e.g., /ipfs/QmId/...).
There was a problem hiding this comment.
@Stebalien even with that, it's way simpler just to tell what has to be done by the user to achieve what they initially wanted to do, rather than having the indirection of going to a webpage/cat a specific file.
There was a problem hiding this comment.
@victorbjelkholm for this particular feature there isn't anything useful written in the docs, but in general I think it is better to point people to docs when enabling an experimental feature so they know the risks (if any) invoiced rather then blindly following some instructions in an error message.
According to #3397 (comment), the status of experimental features is now tracked in a file in the repo, not in an issue.