Shards: Doesn't support ~ in path

[masukomi]

setup:
Created a new shard. Wanted to test it locally before pushing

used this in my dependencies:

  bayes_classifier:
    path: ~/workspace/bayes_classifier

shards kept complaining about

Missing "shard.yml" for "bayes_classifier"

but I was confident it was there (and readable). I tweaked path.cr to indicate _where_ shards was looking when it failed:

$ ~/workspace/shards/shards install
Resolving dependencies
Missing "shard.yml" for "bayes_classifier"
  Expected it at ~/workspace/bayes_classifier/shard.yml
$ ls ~/workspace/bayes_classifier/shard.yml
/Users/masukomi/workspace/bayes_classifier/shard.yml

Modifying the value of the path: to be /Users/masukomi/workspace/bayes_classifier solved the problem.

using ~ to represent the current user's home directory is an incredibly common and decades old practice. This should be supported or _at the very least_ the error message should indicate that ~ isn't supported in paths.

[j8r]

The Path type and File.expand_path supports this special character.
This means shards doesn't use path expansion.

[ysbaddaden]

Only absolute paths are supported for path value. SPEC should probably be updated to reflect that.

Considering ~ as absolute is debatable.

[straight-shoota]

The error message should also be improved. It should not complain about missing shard.yml when the entire parent path does not exist.

[straight-shoota]

@ysbaddaden Why only absolute paths? I've used relative paths quite successfully. And they are very useful when working on a project with multiple related repositories in a project folder. References between them are easy and you don't need to care about where the project folder lives.

[ysbaddaden]

No opinion from me.

It may work with relative paths, but there are no guarantees that it will work properly.

I think we should properly design how the path resolver should work. I never did, mostly because of lack of personal use cases.

[straight-shoota]

It actually seems to work well. I don't see a reason to change anything about how path resolver works. I haven't used it too much, but when I did it went smoothly. Since there are no complains about it, either others have the same positive experience or it's not used much at all. Both ways there's nothing to be done (at the moment).

Except for adding simple features such as home path expansion. That seems very reasonable to me.

[straight-shoota]

Judging by the usage based on shard.yml files available on GitHub, it seems the most common paths are indeed relative. This is obviously not representative, because path resolvers are probably mostly used as a development feature. But it shows that path resolvers are used and used with relative paths.

GitHub search: https://github.com/search?q=%22path%3A%22+filename%3Ashard.yml&ref=advsearch&type=Code&utf8=%E2%9C%93

[masukomi]

It actually seems to work well. I don't see a reason to change anything about how path resolver works - @straight-shoota

It USED to. It no longer does. Not sure when or why it broke.

[straight-shoota]

What exactly doesn't work?

[masukomi]

What exactly doesn't work? - @straight-shoota

it no longer finds the spec file because it no longer expands the ~. that is to say, everything described in this ticket. It USED to function as one would expect with the tilde at the start of the path. it no longer does. now it just fails to find the file.

you are correct that it _used_ to. I have a number of crystal apps I've written that use the ~ notation in the path and worked just fine. Yesterday i built a new shard, went to test it, and the paths are no longer working. I mucked with the code (thus my PR) and proved that the problem was a lack of tilde expansion.

[ysbaddaden]

Oh, you should have said sooner that this used to work. Looking at the path resolver history I believe it broke in https://github.com/crystal-lang/shards/commit/20b4c1777063bcd8243856e7057f3cb801f64934#diff-f34ed0a73607311167396866f0ffc106 which should be using expanded_local_path instead of local_path to determine the spec file path, and everything should be fine again.

Sorry for the noise.