Comments (2)
All of the current open issues around bin/configure
. Just to have easy reference:
#1435 - bin/configure
assumes Debian based system
#1412 - bin/configure
should probably rename origin
even if you skip GitHub setup
#1388 - Repo link in README is not replaced
#1116 - bin/setup
failing for me based on Node version.
#1262 - Add Tunnelmole as an open source alternative to ngrok
#814 - bin/configure
behaves differently for y/n questions when ENTER is pressed (without answering y or n)
#515 - rails not found in bin/configure step
from bullet_train.
Starting to take a look at what all happens in bin/configure
and am just going to kind of live-tweet my findings here.
The first thing we do is make sure that a couple of utility gems are installed and required.
Lines 3 to 12 in f4a32e7
Then we define several utility functions that we use later in the script.
Lines 14 to 61 in f4a32e7
Then we check that the version of ruby on the local system matches what we expect. If we don't have the right version we don't just bail out automatically, we give the user the option to try to continue with whatever ruby version they're using.
Lines 65 to 78 in f4a32e7
Next we check whether homebrew
is installed. We do this check even on Windows and Linux, which is unnecessary because those platforms don't have homebrew
. This should be moved to be a part of the MacOS only conditional branch below.
Lines 80 to 88 in f4a32e7
Now we start a case
statement where we do various things depending on your local OS.
Line 90 in f4a32e7
On darwin
(MacOS) we seem to expect you to have homebrew installed and we just check to see if a few particular libraries are installed via homebrew. This is less than ideal because people may have installed these packages in some other way. Ideally we should check for their existence on the system and not for their existence inside homebrew. (Maybe there's an opportunity to treat darwin
the same way that we treat linux
? That would allow us to remove some code and simplify.)
Lines 91 to 94 in f4a32e7
Continuing with the OS case
statement we have the block for handling linux
. Here we test for things in a variety of ways. For postgresql
and libicu
we use the output of dpkg
to determine whether we think they're installed. For postgresql
we go on to do an additional check by running psql --version
to check the specific version. For libicu
we don't do an additional check beyond dpkg
. For redis
we don't check dpkg
at all and instead only check the output of running redis-cli --version
.
Relying on dpkg
has many of the same drawbacks as relying on homebrew
on MacOS. Namely if people have installed these things in other ways then we can't see them. If they're on a Linux variant that doesn't have dpkg
then our initial checks are likely to fail. Again, the ideal scenario would be checking for their existence on the system and not in a particular package manager. For postgresqul
and redis
this should be easy since there's a CLI command that we can use. I'm not sure how we'd detect libicu
in a platform-and-package-manager-independent way.
Lines 95 to 132 in f4a32e7
To close out the OS case
statement we have a block for platforms that are neither darwin
or linux
(does that basically mean Windows-only?). Here we list the required packages and give people the option to either proceed or not.
Lines 133 to 144 in f4a32e7
Next we try to determine which version of node
is on the system. We do this by checking the output of node -v
, so we're not relying on a particular OS or package manager.
Lines 146 to 164 in f4a32e7
Next we check for yarn
, again by using the CLI. However we don't check the yarn version. We recently began to specify yarn
version 4.2.1
(#1445) so we probably want to robustify this check a little bit.
Lines 166 to 171 in f4a32e7
Next is a block that is currently commented out, with a note about uncommenting it. Should we have already done that?
Lines 173 to 182 in f4a32e7
Next is a block where we ask you if you want to push your new project to GitHub.
Lines 184 to 188 in f4a32e7
After asking about GitHub there's a long block where we do various things.
First we try to change the name of the remote for the starter repo from origin
to bullet-train
. We should probably do this no matter how you answer the GitHub question.
Lines 190 to 199 in f4a32e7
Then comes a block where we pop open a web browser for you so you can create a new repo on GitHub. Once you've done that you're supposed to paste the https
variant of the repo URL. Once you're into this block there doesn't seem to be any way out of it short of aborting the whole script with Ctl-c
or something.
Lines 201 to 219 in f4a32e7
Then to conclude the GitHub-repo-setup block we grab the name of your current branch, and then push it to your new repo as the main
branch. This seems fairly presumptuous to me. If you cloned the starter repo, and then checked out a new branch (git checkout -b run-bin-configure
or something) before running bin/configure
then you'll end up with that local branch pushed to your repo as main
. I certainly wouldn't want that, and I'm having trouble imagining a scenario in which that would be useful. We should probably do a vanilla git push
if we can.
Lines 221 to 224 in f4a32e7
After the GitHub stuff we then run bundle install
and yarn install
.
Lines 227 to 231 in f4a32e7
Next we ask for the name of your application. Then we munge that to create a few variants ("My Test App" => "my_test_app" => "mytestapp" => etc...). Then we do string substitution in a bunch of files to replace instances of "Untitled Application" or "untitled_application" with the new values.
Lines 233 to 265 in f4a32e7
Next up is a block that I don't think is ever run. Due to the way that we capture the skip_github
variable higher up in the script it is always populated with either y
or n
and so doing unless skip_github
always evaluates to unless true
and so we skip the block.
Allegedly this block tries to change the repo link on the "deploy to render" button in README.example.md
, but only if you did not setup GitHub. I think it would probably be better to ask the user if they intend to use Render and then proceed from there. If they don't plan to use Render we should remove the button entirely. And if they do intend to use it we can swap out the repo URLs.
Lines 269 to 273 in f4a32e7
Then we move README.example.md
to overwrite README.md
(so that the new project doesn't contain the full "how to get started with Bullet Train" stuff that's in the main README.md
).
Lines 275 to 276 in f4a32e7
Then we remove a file that is specific to the BT starter repo. There are probably a few more files we could remove here. Specifically some of the workflow files that are for internal core team processes.
Line 278 in f4a32e7
Then we do one more string substitution. It's not clear to me why this one would need to happen after overwriting README.md
. It seems like we could make the change in README.example.md
before overwriting.
Lines 280 to 281 in f4a32e7
Now we have another block related to GitHub setup. Again the seeming intention here differs from what actually happens, again due to how skip_github
is captured. What happens is that we always tell you that you should commit your changes. It seems the intention is that if you did setup GitHub that we should automatically add all the changes, commit them, and then push them to your repo. This again explicitly pushes whatever your current local branch is to main
on the repo. Personally I'm not sure we should add, commit and push for people. At the very least we should ask.
- Do you want us to commit the changes made by this script? y/n?
- Do you want us to push those changes to your repo? y/n?
Lines 283 to 291 in f4a32e7
And finally we output some messages.
Lines 293 to 297 in f4a32e7
I think broadly this script only does a few big-picture things, but they're currently kind of jumbled up in confusing ways.
- check for system-level dependencies like
postgresql
,redis
, etc... ruby
version checking andbundle install
node
/yarn
version checking, andyarn install
- "Untitled Application" => "My Awesome Project" type string substitution and related tasks to change it from being a copy of the starter repo into a "real" application
- GitHub setup
I think ideally we should be able to separate these things out into a collection of smaller scripts (bin/check_dependencies
, bin/check_ruby
, etc...) so that it would be possible to run any one of them at a time. We can tie them all together by calling them from within bin/configure
.
It's also probably worth thinking about the order in which this all happens. For instance, is it really necessary to know that all the dependencies are installed before we do string substitution and setup GitHub? Is it realistic to to do the string substitution first, then GitHub, then local dependency checking?
To put it a different way: Should you be blocked from starting a new app and pushing it to GitHub just because you don't have all of your local dependencies satisfied? (And satisfied via the package managers that we know how to interrogate?)
from bullet_train.
Related Issues (20)
- undefined method 'owning_association' HOT 1
- undefined method `underscore' for nil
- Super scaffolding makes some incorrect assumptions about naming HOT 2
- Join model scaffolder throws an error if you don't supply class names
- Indentation in scaffolded tests is wrong
- Super scaffolding any model causes the OpenAPI test to start failing HOT 5
- Including Sentry in `app.json` breaks review apps on heroku
- Some of the `bin/configure` stuff would be better in `bin/setup` HOT 1
- A fresh app instantly runs out of memory on heroku
- We shoud activate jemalloc by default on heroku
- Can you super scaffold something that doesn't belong to a team? HOT 1
- Running super_scaffold breaks with error message "Model file not found" even though it was generated
- Should we consider switching to Playwright instead of Selenium for driving system tests?
- Unmet dependencies HOT 4
- Problems with `overmind` + `asdf`? HOT 1
- Redirect loop if a team has no members
- Docs for MFA seem to be incomplete HOT 1
- `devise-two-factor` is broken without jQuery
- Support for passkeys?
- Webhook attempt numbers aren't displayed properly
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bullet_train.