docs: use symbolic link for `bt` binstub
Closed this issue · 3 comments
Motivation
I don't think this is technically a bug or feature request so I used docs. I would propose modifying bt
binstub with symbolic link.
Now bin/bridgetown
and bin/bt
are the same commands. Since bundler generates bin/bridgetown
so bundler can update the binstub technically (or other tools). Using a symbolic link would allow tools like bundler to make such changes.
Suggestion
This means a change in bridgetown-core/lib/bridgetown-core/commands/new.rb
.
Bridgetown.with_unbundled_env do
inside(path) do
run "bundle install", abort_on_failure: true
run "bundle binstubs bridgetown-core"
# bundle's binstub is a wrapper to call the actual executable in bridgetown-core's executable.
# Use symbolic link to allow bundler or other tools to change binstubs reliably.
run "cd bin && ln -s bridgetown bt"
end
@erickguan I'm with you on this in spirit, but I'm concerned that there are situations where Git won't honor symlinks from an existing repo (the core.symlinks
config setting can sometimes end up as false
), in which case this solution wouldn't work.
Perhaps we could simplify the code inside of the bt
script so it simply runs the bridgetown
script? That way we don't need to worry about symlinks.
Good point! One other way is to set up bin/bt
and set s.executables = ["bridgetown", "bt"]
. bin/bt
can either be a symbolic link or a ruby script load bin/bridgetown
. Then bundler will manage bt
binstub too. This is as if we modify bt
as the last line of binstub would be load Gem.bin_path("bridgetown-core", "bt")
.
Though Bridgetown creates bt
binstub when run new command, it feels rare that someone is still using FAT which has core.symlinks=false
by default.
What do you think?
@erickguan I like the idea of just adding the new bt
executable which accomplishes the same thing. Do you think you could give that a try in a PR? Happy to assist.