Rails 3 beta2

[Don Park]

http://weblog.rubyonrails.org/2010/4/1/rails-3-0-second-beta-release

The beta2 of Ruby on Rails 3.0 was just tagged and announced. The blog
post says "we’ve made huge strides since the last release and so have
auxiliary tools like Bundler." Hopefully some of what was brought up
in Igal's talk on Bundler have been addressed.

Don

[Igal Koshevoy]

On 04/01/2010 03:06 PM, Don Park wrote:

http://weblog.rubyonrails.org/2010/4/1/rails-3-0-second-beta-release

The beta2 of Ruby on Rails 3.0 was just tagged and announced. The blog
post says "we�ve made huge strides since the last release and so have
auxiliary tools like Bundler." 

This is good news. Any interest in having a mid-month activity meeting to explore these changes and throwing around some code to exercise them?

Hopefully some of what was brought up in Igal's talk on Bundler have been addressed

The following complaints that I raised still remain:

1. Don't want to mix-and-match gem managers (gemrc, rip, etc)
2. Rails 2 integration is ugly
3. Can't easily require gems outside manifest on the fly
4. Passenger requires locked environment?
5. `bundle install` accesses network even though it shouldn't, consider using `bundle check || bundle install`
6. `bundle check` checks everything, doesn't accept `--with=GROUP` or `--without=GROUP`
7. `bundle install` accepts `--without=GROUP`, but not `--with=GROUP`
8. `bundle check` rewrites the locked environment file when checked even if same, annoying for versioning

If someone wants to team up to work on this, I'm pretty sure we can solve everything other than #1 quickly. This may make for a good mini sprint. Interested?

I'll bring up the suggestion for these two activities again at the meeting.

-igal

[Andrew Kurtz]

Dependency management has been a huge headache for me. I think polishing bundler would be awesome. Count me in.

On Fri, Apr 2, 2010 at 12:37 PM, Igal Koshevoy <ig...@pragmaticraft.com> wrote:

On 04/01/2010 03:06 PM, Don Park wrote:

http://weblog.rubyonrails.org/2010/4/1/rails-3-0-second-beta-release

The beta2 of Ruby on Rails 3.0 was just tagged and announced. The blog
post says "we’ve made huge strides since the last release and so have
auxiliary tools like Bundler." 

This is good news. Any interest in having a mid-month activity meeting to explore these changes and throwing around some code to exercise them?

Hopefully some of what was brought up in Igal's talk on Bundler have been addressed

The following complaints that I raised still remain:

1. Don't want to mix-and-match gem managers (gemrc, rip, etc)
2. Rails 2 integration is ugly
3. Can't easily require gems outside manifest on the fly
4. Passenger requires locked environment?
5. `bundle install` accesses network even though it shouldn't, consider using `bundle check || bundle install`
6. `bundle check` checks everything, doesn't accept `--with=GROUP` or `--without=GROUP`
7. `bundle install` accepts `--without=GROUP`, but not `--with=GROUP`
8. `bundle check` rewrites the locked environment file when checked even if same, annoying for versioning

If someone wants to team up to work on this, I'm pretty sure we can solve everything other than #1 quickly. This may make for a good mini sprint. Interested?

I'll bring up the suggestion for these two activities again at the meeting.

-igal

--
You received this message because you are subscribed to the Google Groups "pdxruby" group.
To post to this group, send email to pdx...@googlegroups.com.
To unsubscribe from this group, send email to pdxruby+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pdxruby?hl=en.

[Reid Beels]

>> Hopefully some of what was brought up in Igal's talk on Bundler have been addressed
> The following complaints that I raised still remain:
> • Don't want to mix-and-match gem managers (gemrc, rip, etc)
> • Rails 2 integration is ugly
> • Can't easily require gems outside manifest on the fly
> • Passenger requires locked environment?
> • `bundle install` accesses network even though it shouldn't, consider using `bundle check || bundle install`

It seems to me that the reason bundle install accesses the network is because it is meant to be able to handle updates. If we were to throw code at bundler, it would be important to either create a new command, or a new option to the install command that would tell it to check for updates to installed dependencies, as well as installing them from scratch.

> • `bundle check` checks everything, doesn't accept `--with=GROUP` or `--without=GROUP`

> • `bundle install` accepts `--without=GROUP`, but not `--with=GROUP`
> • `bundle check` rewrites the locked environment file when checked even if same, annoying for versioning
> If someone wants to team up to work on this, I'm pretty sure we can solve everything other than #1 quickly. This may make for a good mini sprint. Interested?

I'd be up for some mini-sprinting around this, if only to become more familiar with how bundler works internally.

I'll also add my own complaint from last meeting
* There is no way to tell bundler to use a certain lib or include directory when installing gems with native extensions.

Reid

[Igal Koshevoy]

On 04/05/2010 11:06 AM, Reid Beels wrote:
>> The following complaints that I raised still remain:[...] `bundle

>> install` accesses network even though it shouldn't, consider using
>> `bundle check || bundle install`
> It seems to me that the reason bundle install accesses the network is because it is meant to be able to handle updates. If we were to throw code at bundler, it would be important to either create a new command, or a new option to the install command that would tell it to check for updates to installed dependencies, as well as installing them from scratch.
>

Agreed. If I'd designed this, I'd have called Bundler's "install"
command something like "upgrade" or "install-or-upgrade", and provided
an "install" command that behaves differently. However, I understand
that it's important to retain the semantics of the library's
terminology. I'd probably be looking to add a command/option like
"bundle checkorinstall" or "bundle prepare" or "bundle install
--if-needed" or "bundle install --no-upgrade" or "bundle check
--install". I don't particularly like any of these names, so if someone
has a better suggestion, I'd like to hear it.

>> If someone wants to team up to work on this, I'm pretty sure we can solve everything other than #1 quickly. This may make for a good mini sprint. Interested?
>>
> I'd be up for some mini-sprinting around this

Great!

> if only to become more familiar with how bundler works internally.
>

Spoiler: no documentation, poor naming, unclear flow, excessive
indirection, and much unneeded code. :(

> I'll also add my own complaint from last meeting
> * There is no way to tell bundler to use a certain lib or include directory when installing gems with native extensions.
>

Yeah, that's a problem.

-igal

[David Cato]

Igal Koshevoy wrote ...

> The following complaints that I raised still remain:
>

> 1. Don't want to mix-and-match gem managers (gemrc, rip, etc)
> 2. Rails 2 integration is ugly
> 3. Can't easily require gems outside manifest on the fly
> 4. Passenger requires locked environment?
> 5. `bundle install` accesses network even though it shouldn't,

> consider using `bundle check || bundle install`

> 6. `bundle check` checks everything, doesn't accept `--with=GROUP` or
> `--without=GROUP`
> 7. `bundle install` accepts `--without=GROUP`, but not `--with=GROUP`
> 8. `bundle check` rewrites the locked environment file when checked

> even if same, annoying for versioning

Another issue I ran across is the inability to specify a library name
that's different that the gem name, i.e., there doesn't seem to be an
equivalent to

config.gem 'rmagick', :lib => 'RMagick'

> If someone wants to team up to work on this, I'm pretty sure we can
> solve everything other than #1 quickly. This may make for a good mini
> sprint. Interested?

I'm not sure what your definition of quickly is, or perhaps I'm a bit
more pessimistic on how quickly the problems can be resolved, but I'd be
interested in a code sprint to work on them.

--
David Cato

[Igal Koshevoy]

On 04/06/2010 09:42 AM, David Cato wrote:
> Another issue I ran across is the inability to specify a library name
> that's different that the gem name, i.e., there doesn't seem to be an
> equivalent to
>
> config.gem 'rmagick', :lib => 'RMagick'
>

The new Bundler syntax for this looks like:
gem 'rmagick', :require => 'RMagick'

I really wish they'd (1) documented this more clearly and (2) provided
backwards compatibility since most people that will use Bundler are
coming from a config.gem background. Maybe one of the things we provide
a patch for is something that either warns the user of unknown options
that are being ignored, or a handler that accepts these old-style
arguments but displays deprecation warnings. I ran into a similar
problem when I inadvertantly specified the versions of my desired gems
using the congi.gem-style :version option, which Bundler silently
ignored and then was surprised when I was getting different versions of
things than I expected.

>> If someone wants to team up to work on this, I'm pretty sure we can
>> solve everything other than #1 quickly. This may make for a good mini
>> sprint. Interested?
>>
> I'm not sure what your definition of quickly is, or perhaps I'm a bit
> more pessimistic on how quickly the problems can be resolved, but I'd be
> interested in a code sprint to work on them.
>

Great. Agreed. In this case, I meant quickly as in hours to days of work.

-igal

[Kyle Drake]

I've had similar frustrations with Bundler. I switched to the
bundler08 gem after they started doing a heavy refactor of the master
branch. They completely re-wrote the interface on me, I'm not sure if
they're still heavily working on it, but I eventually need to switch
back when things stabilize.

We've never had a problem using bundler with passenger, but due to the
way passenger works, you never get a truly isolated gem structure.

-Kyle