fly.io-rails 0.0.2-x64-mingw32 → 0.0.3-x64-mingw32

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: c3c28e311b358c82924ee67fbeaa41563ae947e8f7ab678cd92e669dce1af22d
-  data.tar.gz: 3a102a8f1b388dd6369ebbb58545fac05a6fc4b20e7d51713c14043ec35dda39
+  metadata.gz: d57f3b28e7fd2c3e14750163862eeab99067b43bb335e3292c917ef8aefb4993
+  data.tar.gz: 4e260fb9da1d52a5fe78ea44a223cfb001a67ba4dce8f73b652344d62a65bf49
 SHA512:
-  metadata.gz: 573b5e778a7001e80a60c73e29ed18fa31d85f58e1b91c2156d9c85cb5fc1dd5cf5049ac038d6bb2428cb5ec3624d754a44567a4721c8b924f3a74443ad71d14
-  data.tar.gz: b0816c934088d44aec1c90384cb2d2e324e062c7a7cc6ef1840919228d2731a6f08e97051eff630271a16230de0bda9815bb97a2a76e8aa2fecdcb88532a4c1b
+  metadata.gz: 9e6392b4e88b5324194900addc36de27b78a2b1bcad8da0792472a82245bbd2bcf3617260b077ad51c342eb639f06e4c9119d86462921b5df5b7d7bf7c544c0a
+  data.tar.gz: 730d3acae8cb1bcfd830fc3aacdd40edbf63241d48442ccf052208a74384ebbc931a237b8c73d02872f75bde891a821173502c1a50e66ad2a2ea325c5b239c8d

data/README.md

@@ -6,26 +6,7 @@ Add [Fly.io](https://fly.io) support to [Rails](https://rubyonrails.org/).
 
 <u>pre-alpha</u>.
 
-In fact, the gem has not been yet been pushed to the rubygems
-repository as while creating a github repository is an easily reversible act,
-wiping all memory of a mis-named gem is considerably more challenging.
-
-It currently is possible to build the gem files, install the prerequisite
-`ruby-fly` gem, and then install the platform specific gem using `--local`.
-You can also add the gem to your Gemfile using the `path:` argument to the
-`gem` statement/method call.  Of course, all of this will be taken care of
-for you once this gem has been published.
-
-## Quickstart/summary
-
-```sh
-rails new demo
-cd demo
-bundle add fly.io-rails
-flyctl auth login
-bin/rails fly:launch
-bin/rails deploy
-```
+For usage instructions, see [Fly.io Rails Advanced Guide: Terraform](https://fly.io/docs/rails/advanced-guides/terraform/).
 
 ## Build instructions
 
@@ -38,152 +19,3 @@ every supported platform as well as an additional gem that doesn't
 include a binary.
 
 To download new binaries, run `rake clobber` then `rake package` agein.
-
-## Description
-
- -  `bundle add fly.io-rails`
-    
-    This will install `ruby-fly` middleware, add new Rails tasks, extend the
-    channel and job generatotors, and platform binaries for
-    [flyctl](https://github.com/superfly/flyctl#readme).  I've followed the
-    trail blazed by [nokogiri](https://nokogiri.org/) and others to make
-    platform binaries happen.
-
- - `bin/rails fly:launch`
-
-   This won't be a mere front enty to [`flyctl
-   launch`](https://fly.io/docs/flyctl/launch/).  It will use
-   [`thor`](https://github.com/rails/thor#thor) to rewrite the configuration
-   for the `production` environment as well as tweak the `Dockerfile` and
-   `fly.toml` based on your application - in particular the configuration for
-   ActiveRecord, ActiveJob, and ActionCable.  The people at Fly will know what
-   databases and message queing systems work best on their platform and should
-   make it easy to do the right thing.
-
-   As an example, the default production database for a new application in
-   Rails is sqlite3.  Either this will need to be replaced by Postgre in
-   the Rails configuration *or* a volume will need to be defined, mounted,
-   and the Rails configuration modified to point to the new mount point.
-
-   This gem should pick one of those paths as the default, and provide an option to chose other paths.
-
- - `bin/rails generate channel`, `bin/rails generate job`, etc.
-
-   Rails applications are generally not invented fully formed.  They evolve and
-   add features.  I don't want people to think about having to configure rails
-   AND configure fly when then add features.  Generators that developers
-   already use today should be able to update both the Rails and Fly
-   configurations in a consistent manner.
-
-For now, both the Rails tasks and generators don't actually modify the Rails
-configuratio to support Fly, instead they merely output the string `Configuring
-fly...`.  Let your imagination run wild.
-
-## Motivation
-
-Oversimplifying and exagerating to make a point, `flyctl launch` generates an
-initial fly configuration based on the state of the application at launch time
-but leaves configuring your Rails application up to you.  The initial Fly
-configuration may need to be tweaked, and both the fly and Rails configurations
-will need to be maintained as the application evolves.
-
-From a Rails developer perspective, this makes fly an additional framework that
-must be learned and attended to.
-
-This can all be changed with a single `bundle add` command.  Everything from
-new `rails` tasks to extending the behavior of existing generators to making
-changes to configuration to monkeypatching Rails internals itself are on the
-table.
-
-A few sublte but important mindset changes are necessary to pull this off:
-
-  * Instead of "we support every (or perhaps even only 'most') Rails
-    configuration" the mindset we should strive for is "we provide a default
-    production configuration that works for most, and provide options to add or
-    replace components as desired".
-
-    We should be bold and daring.  We should chose a default web server, a
-    default database, a default active job queue adapter, a default action
-    cable subscription adapter, etc., etc., etc.
-
-    Over time, this should encompas everything needed for monitoring and
-    deployment.  Requirements for things like log file management should be
-    anticipated and accounted for.
-
-  * Any configuration artifact that is generated and needs to be checked into
-    the application's source control repository needs to be [beautiful
-    code](https://rubyonrails.org/doctrine#beautiful-code).  If you look at
-    configuration files provided by either `rails new` or by rails generators,
-    they have comments.  They don't configure things that don't apply to you.
-
-    A concrete example: Rails 7 applications default to import maps.  A
-    `Dockerfile` generated for such an app should not contain code that deals
-    with `yarn` or `node_modules`. 
-
-And as a closing remark - to be fair adding Rails support to Fly and adding Fly
-support to Rails are more complementary than competing efforts.  
-
-## Future
-
-> Que sera, sera
-
--- Doris Day
-
-I don't know what the future is going to hold, but some guesses:
-
-  * It is plausible that a code base written in Ruby and with access to
-    libraries like [Thos](http://whatisthor.com/) and focused exclusively on
-    Rails may attract more contributions from the Rails community than a
-    codebase written in Go and targetting many disparate frameworks.
-  * Flyctl launch can continue to provide a basic Fly configuration for Rails,
-    but if this effort is successful these configurations would largely be
-    replaced by more tailors configurations that are updated by generators and
-    rake tasks as the application evolves.
-  * Not every flyctl command needs to have a Rails wrapper -- only the common
-    task do.  It is quiet OK for developers to deal directly with fly when it
-    makes sence to do so.  But those flyctl command that are wrapped may need
-    options added that enable them to be run without the need to prompt the
-    user.
-  * This gem could be built and published alongside the flyctl executables, and
-    `flyctl version update` could detect whether or not it was installed as a
-    gem and react appropriately.
-
-## Call to Action
-
-> good ideas and bad code build communities, the other three combinations do
-> not
-
--- Stefano Mazzocchi
-
-> the best way to get the right answer on the internet is not to ask a
-> question; it's to post the wrong answer.
-
--- Ward Cunningham
-
-I don't presume that any specific line of code in this initial implementation
-will last the test of time.  Heck, I'm not even confident enough in the
-proposed name to register the gem, though the name does feel *rails-like* -
-just take a look at any Rails `Gemfile` to see.
-
-My hope is that there is enough scaffolding here to not only make clear what
-the possibilities are, but also enough structure so that it is fairly obvious
-where new logic should go, together there is not only enough promise and
-structure to attract a community.
-
-Some starter ideas:
-
- * Can we make `bin/rails deploy` smart enough to invoke `flyctl auth login` if
-   you are not logged in and `bin/rails fly:launch` if the application had not
-   previously been launched, with the goal of reducing the number of commands a
-   user has to issue to get started.  Also I'm impressed by the way auth login
-   launches a browser, can we do the same for fly launch?
-
- * While a number of application configuration changes are made through
-   generators, not all are.  For example, upgrading the version of Ruby to be
-   used.  Perhaps we could create tasks for some of these, but likely it will
-   be worthwhile to create a `fly:reconfig` task.
-
-Finally, once this repository is in the superfly github organization and
-a gem has been published, this README should be rewritten from focus on
-raison d'être and to a focus on what value it would bring to those that
-install and use it.

data/lib/fly.io-rails/version.rb

@@ -1,3 +1,3 @@
 module Fly_io
-  VERSION = '0.0.2'
+  VERSION = '0.0.3'
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: fly.io-rails
 version: !ruby/object:Gem::Version
-  version: 0.0.2
+  version: 0.0.3
 platform: x64-mingw32
 authors:
 - Sam Ruby