Rainbows! Rack HTTP server user/dev discussion
 help / color / mirror / code / Atom feed
From: Hedge Hog <hedgehogshiatus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "Rainbows! list" <rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org>
Subject: Re: TAN: why Bundler? (was: Re: problem with rainbows 3.2.0 and rbx)
Date: Sun, 1 May 2011 12:09:38 +1000	[thread overview]
Message-ID: <BANLkTim0h207_Y_CRrYeTTg=6948aabnZw@mail.gmail.com> (raw)
In-Reply-To: <20110430175124.GA3040-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>

On Sun, May 1, 2011 at 3:51 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
>> 2) your app uses Bundler?
>
> Old idea, but I'm not sure why more webapps aren't just distributed as
> gems themselves.

In my case I considered and, after much effort, rejected this
approach.  I'm moving, progressively, to continuous deployment (via
Whiskey Disk).
Having my web app depend on rubygems is a non starter.

The objective is to have the web-app/component deployed in the time it
currently takes to sync the rubygems index and resolve dependencies
(see the Whiskey Disk presentation).
Of course I could use some CDN directly, but you see the path I'd be
heading down: writing a custom package deployer.
Of course I do use Ruby gems for 3rd party library dependencies, and
one thing I'm doing is moving some current 'app-level' code out into a
slow changing gem, but the actual web-app?  Not likely.

>  Or even something like this which just declares
> dependencies:
>
> ----------------- gemspec_sandbox_demo.gemspec --------------------
> Gem::Specification.new do |s|
>  s.name = %q{gemspec_sandbox_demo}
>  s.version = '1'
>  s.author = "J. Random Hacker"
>  s.homepage = "http://example.com/"
>  s.email = "root@example.com"
>  s.summary = "no need to use sandboxing tools"
>  s.description = <<EOF
> Apps that use gems that don't conflict can just use a dummy gem built
> from a gemspec like this one.
>
> There are a few missing pieces, like not being able to use git://
> repos for gems or specify build options for C extensions, but it's
> probably enough for a good number of use cases.
> EOF
>  s.add_dependency(%q<mysql2>, "~> 0.3")
>  s.add_dependency(%q<sequel>, "~> 3.22")
>  s.add_dependency(%q<sinatra>, "~> 1.0")
> end
> -------------------------------------------------------------------
>
> And then just `gem build foo.gemspec && gem install ./foo-1.gem`
> in the deploy.

Using Git and SSH I'm getting to the point where the deploy will be
done in the time Rubygems index sync's and Bundler resolves its
dependency calculations and actions.

>
> ...But many years ago I gave up and just decided
> packaging/dependency/deployment problems are just unsolvable

I think of deploying as being _very_ weakly related to packaging and
resolving dependencies.  Before their problems are solvable, their
roles need to be clearly delineated in your app/project.

> because
> there's always (at least) one special case in *every* case that $TOOL
> doesn't/can't solve :<

I'm not sure it is and issue of a 'special case', rather deployment
patterns and _frequency_ are those that package managers were never
intended to address.
In my mind packagers/dependency-resolvers are targeted at the
infrequently-changing-code, and widely adopted use cases.
Say monthly changes as the most frequent - you could push the limits
and maybe have daily gem updates, but now the packager's overhead vs
the size of the change means you'll be more and more reluctant to get
the small change in your deployed code out there - and waiting for
small changes to grow into bigger changes, in my experience, makes
things more complex and more fraught.

I tried hard to fix Bundler's _many_ Git issues, see the pull
requests, but I concluded it is a wasted effort - the core Devs don't
have Git use  cases as one of their itches, and I genuinely thank
indirect for being explicit about this. I realized that maybe they had
reached the conclusion I did: Git in Bundler is really for convenience
of library dev work.
Trying to make it fulfill (continuous) app deployment work is 'nuts'.
If your app deployment is not continuous, then just bundle/gemify it
as usual and use Std Bundler/Rubygems in one of your infrequent
deploys, rather than get Git involved for the sake of having it
involved.

My 2c

>
> --
> Eric Wong
> _______________________________________________
> Rainbows! mailing list - rainbows-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rainbows-talk
> Do not quote signatures (like this one) or top post when replying
>



-- 
πόλλ' οἶδ ἀλώπηξ, ἀλλ' ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
  Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://wiki.hedgehogshiatus.com
_______________________________________________
Rainbows! mailing list - rainbows-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

  parent reply	other threads:[~2011-05-01  2:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-27 16:25 problem with rainbows 3.2.0 and rbx Mike Perham
     [not found] ` <BANLkTimE7vo2_pRDdcVNN5vNA2fphP4-4Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-04-27 17:12   ` Mike Perham
2011-04-27 17:55   ` Eric Wong
     [not found]     ` <20110427175523.GA31654-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2011-04-27 18:06       ` Eric Wong
     [not found]         ` <20110427180635.GA19302-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2011-04-28  6:47           ` Eric Wong
2011-04-29 23:58       ` Mike Perham
     [not found]         ` <BANLkTikTugt46DfKVJtt3_fTm+X-j9U2Rw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-04-30  1:19           ` Eric Wong
     [not found]             ` <20110430011926.GA15387-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2011-04-30 16:10               ` Mike Perham
     [not found]                 ` <BANLkTi=itrufRkdQsp7M5jaBS2trnm5dMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-04-30 17:14                   ` Eric Wong
     [not found]                     ` <20110430171428.GB29282-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2011-04-30 17:51                       ` TAN: why Bundler? (was: Re: problem with rainbows 3.2.0 and rbx) Eric Wong
     [not found]                         ` <20110430175124.GA3040-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2011-05-01  2:09                           ` Hedge Hog [this message]
2011-04-30 21:08                       ` problem with rainbows 3.2.0 and rbx Mike Perham
     [not found]                         ` <BANLkTi=t6z_5psK6AJy=XrOZmXjX0GW-pg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-01  1:47                           ` Eric Wong
     [not found]                             ` <20110501014703.GA16332-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2011-05-01  4:26                               ` Mike Perham
     [not found]                                 ` <BANLkTinReZFusAimFSF=RcPkm-1N-=Y1Sg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-01  6:38                                   ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://yhbt.net/rainbows/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTim0h207_Y_CRrYeTTg=6948aabnZw@mail.gmail.com' \
    --to=hedgehogshiatus-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhbt.net/rainbows.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).