Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Alexey Verkhovsky-2
Brian:

I see you added Gemfile to CC.rb. Not having external dependencies, binary gems etc - this was, in fact, by design.

The rationale was that this tool should be easy to install for people who know nothing about Ruby (because it was used on non-Ruby gigs; probably still is). Therefore, it should only require Ruby and nothing else (not even rubygems). Everything else is vendored.

I have a tentative (i.e., not extremely convinced) opinion that it better remain this way.

--Alex


_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Alexey Verkhovsky-2
I do have a rather strong opinion that it should not use binary gems. This adds a big barrier to entry, especially on Windoze.

On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky <[hidden email]> wrote:
Brian:

I see you added Gemfile to CC.rb. Not having external dependencies, binary gems etc - this was, in fact, by design.

The rationale was that this tool should be easy to install for people who know nothing about Ruby (because it was used on non-Ruby gigs; probably still is). Therefore, it should only require Ruby and nothing else (not even rubygems). Everything else is vendored.

I have a tentative (i.e., not extremely convinced) opinion that it better remain this way.

--Alex




--
Alexey Verkhovsky
http://alex-verkhovsky.blogspot.com/
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]


_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Chad Woolley
If we use bundler with packaged gems (which we should, if we aren't),
that's essentially the same as vendoring them, which is what we did
before.

Agreed on avoiding use of binary gems.  Are we using any?  If so, we
should use a non-binary equivalent if at all possible.

On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
<[hidden email]> wrote:

> I do have a rather strong opinion that it should not use binary gems. This
> adds a big barrier to entry, especially on Windoze.
>
> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
> <[hidden email]> wrote:
>>
>> Brian:
>>
>> I see you added Gemfile to CC.rb. Not having external dependencies, binary
>> gems etc - this was, in fact, by design.
>>
>> The rationale was that this tool should be easy to install for people who
>> know nothing about Ruby (because it was used on non-Ruby gigs; probably
>> still is). Therefore, it should only require Ruby and nothing else (not even
>> rubygems). Everything else is vendored.
>>
>> I have a tentative (i.e., not extremely convinced) opinion that it better
>> remain this way.
>>
>> --Alex
>>
>
>
>
> --
> Alexey Verkhovsky
> http://alex-verkhovsky.blogspot.com/
> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>
>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Brian Guthrie-3
To the best of my knowledge, we do not have any dependencies on binary
gems at the moment. But even if we did, I don't see why it should be a
problem as long as Windows equivalents for those gems exist. I agree
that there's an expectation that CC.rb should be as widely compatible
as possible. I haven't had a chance to test every platform since the
upgrade, but I'm trying to remain true to the spirit of that goal.

But I don't see any good reason for the expectation that a Windows
user should be able to check out _the source code_ and immediately run
it. If they check out the source code, they can bundle install like
any other Ruby developer. If they install it as a gem, then let gem
dependencies be handled and installed as per normal. Either case would
handle binary gems just fine.

But if they just want a dependency-free _binary download_, there's no
reason why we can't package a zipfile that includes all dependencies
(using bundle install --deployment, for example) and make that
available. Such an artifact should be the output of a potential
Windows release build.

You may have noticed that I haven't checked in a Gemfile.lock either.
In case you were wondering why, it's because the last time I tried to
use Bundler on a cross-platform project (fairly recently--six months
ago or so) it failed to lock down dependencies in a platform-agnostic
way. This probably isn't an issue now, because there are no binary
gems, and so perhaps we should reconsider. But it would be if there
were.

Cheers,

Brian

On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <[hidden email]> wrote:

> If we use bundler with packaged gems (which we should, if we aren't),
> that's essentially the same as vendoring them, which is what we did
> before.
>
> Agreed on avoiding use of binary gems.  Are we using any?  If so, we
> should use a non-binary equivalent if at all possible.
>
> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
> <[hidden email]> wrote:
>> I do have a rather strong opinion that it should not use binary gems. This
>> adds a big barrier to entry, especially on Windoze.
>>
>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>> <[hidden email]> wrote:
>>>
>>> Brian:
>>>
>>> I see you added Gemfile to CC.rb. Not having external dependencies, binary
>>> gems etc - this was, in fact, by design.
>>>
>>> The rationale was that this tool should be easy to install for people who
>>> know nothing about Ruby (because it was used on non-Ruby gigs; probably
>>> still is). Therefore, it should only require Ruby and nothing else (not even
>>> rubygems). Everything else is vendored.
>>>
>>> I have a tentative (i.e., not extremely convinced) opinion that it better
>>> remain this way.
>>>
>>> --Alex
>>>
>>
>>
>>
>> --
>> Alexey Verkhovsky
>> http://alex-verkhovsky.blogspot.com/
>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>
>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> [hidden email]
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Chad Woolley
Not checking in Gemfile.lock seems like a bad idea.  This allows
unspecified/indirect dependencies to float, which is almost guaranteed
to cause breakages as the world moves on.

On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie
<[hidden email]> wrote:

> To the best of my knowledge, we do not have any dependencies on binary
> gems at the moment. But even if we did, I don't see why it should be a
> problem as long as Windows equivalents for those gems exist. I agree
> that there's an expectation that CC.rb should be as widely compatible
> as possible. I haven't had a chance to test every platform since the
> upgrade, but I'm trying to remain true to the spirit of that goal.
>
> But I don't see any good reason for the expectation that a Windows
> user should be able to check out _the source code_ and immediately run
> it. If they check out the source code, they can bundle install like
> any other Ruby developer. If they install it as a gem, then let gem
> dependencies be handled and installed as per normal. Either case would
> handle binary gems just fine.
>
> But if they just want a dependency-free _binary download_, there's no
> reason why we can't package a zipfile that includes all dependencies
> (using bundle install --deployment, for example) and make that
> available. Such an artifact should be the output of a potential
> Windows release build.
>
> You may have noticed that I haven't checked in a Gemfile.lock either.
> In case you were wondering why, it's because the last time I tried to
> use Bundler on a cross-platform project (fairly recently--six months
> ago or so) it failed to lock down dependencies in a platform-agnostic
> way. This probably isn't an issue now, because there are no binary
> gems, and so perhaps we should reconsider. But it would be if there
> were.
>
> Cheers,
>
> Brian
>
> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <[hidden email]> wrote:
>> If we use bundler with packaged gems (which we should, if we aren't),
>> that's essentially the same as vendoring them, which is what we did
>> before.
>>
>> Agreed on avoiding use of binary gems.  Are we using any?  If so, we
>> should use a non-binary equivalent if at all possible.
>>
>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
>> <[hidden email]> wrote:
>>> I do have a rather strong opinion that it should not use binary gems. This
>>> adds a big barrier to entry, especially on Windoze.
>>>
>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>>> <[hidden email]> wrote:
>>>>
>>>> Brian:
>>>>
>>>> I see you added Gemfile to CC.rb. Not having external dependencies, binary
>>>> gems etc - this was, in fact, by design.
>>>>
>>>> The rationale was that this tool should be easy to install for people who
>>>> know nothing about Ruby (because it was used on non-Ruby gigs; probably
>>>> still is). Therefore, it should only require Ruby and nothing else (not even
>>>> rubygems). Everything else is vendored.
>>>>
>>>> I have a tentative (i.e., not extremely convinced) opinion that it better
>>>> remain this way.
>>>>
>>>> --Alex
>>>>
>>>
>>>
>>>
>>> --
>>> Alexey Verkhovsky
>>> http://alex-verkhovsky.blogspot.com/
>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>>
>>>
>>> _______________________________________________
>>> Cruisecontrolrb-developers mailing list
>>> [hidden email]
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> [hidden email]
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Brian Guthrie-3
If you specify a dependency on a binary gem, and attempt to lock your
project to that gem, Bundler will lock the version that's valid for
your current platform but not every conceivable platform. I consider
this a major flaw in their locking model, but I believe this may get
fixed in 1.1. I'll give it a shot in Windows today if I get the
chance. If everything looks okay, I'll try checking in the lockfile.

Brian

On Thu, May 19, 2011 at 8:31 AM, Chad Woolley <[hidden email]> wrote:

> Not checking in Gemfile.lock seems like a bad idea.  This allows
> unspecified/indirect dependencies to float, which is almost guaranteed
> to cause breakages as the world moves on.
>
> On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie
> <[hidden email]> wrote:
>> To the best of my knowledge, we do not have any dependencies on binary
>> gems at the moment. But even if we did, I don't see why it should be a
>> problem as long as Windows equivalents for those gems exist. I agree
>> that there's an expectation that CC.rb should be as widely compatible
>> as possible. I haven't had a chance to test every platform since the
>> upgrade, but I'm trying to remain true to the spirit of that goal.
>>
>> But I don't see any good reason for the expectation that a Windows
>> user should be able to check out _the source code_ and immediately run
>> it. If they check out the source code, they can bundle install like
>> any other Ruby developer. If they install it as a gem, then let gem
>> dependencies be handled and installed as per normal. Either case would
>> handle binary gems just fine.
>>
>> But if they just want a dependency-free _binary download_, there's no
>> reason why we can't package a zipfile that includes all dependencies
>> (using bundle install --deployment, for example) and make that
>> available. Such an artifact should be the output of a potential
>> Windows release build.
>>
>> You may have noticed that I haven't checked in a Gemfile.lock either.
>> In case you were wondering why, it's because the last time I tried to
>> use Bundler on a cross-platform project (fairly recently--six months
>> ago or so) it failed to lock down dependencies in a platform-agnostic
>> way. This probably isn't an issue now, because there are no binary
>> gems, and so perhaps we should reconsider. But it would be if there
>> were.
>>
>> Cheers,
>>
>> Brian
>>
>> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <[hidden email]> wrote:
>>> If we use bundler with packaged gems (which we should, if we aren't),
>>> that's essentially the same as vendoring them, which is what we did
>>> before.
>>>
>>> Agreed on avoiding use of binary gems.  Are we using any?  If so, we
>>> should use a non-binary equivalent if at all possible.
>>>
>>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
>>> <[hidden email]> wrote:
>>>> I do have a rather strong opinion that it should not use binary gems. This
>>>> adds a big barrier to entry, especially on Windoze.
>>>>
>>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>>>> <[hidden email]> wrote:
>>>>>
>>>>> Brian:
>>>>>
>>>>> I see you added Gemfile to CC.rb. Not having external dependencies, binary
>>>>> gems etc - this was, in fact, by design.
>>>>>
>>>>> The rationale was that this tool should be easy to install for people who
>>>>> know nothing about Ruby (because it was used on non-Ruby gigs; probably
>>>>> still is). Therefore, it should only require Ruby and nothing else (not even
>>>>> rubygems). Everything else is vendored.
>>>>>
>>>>> I have a tentative (i.e., not extremely convinced) opinion that it better
>>>>> remain this way.
>>>>>
>>>>> --Alex
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alexey Verkhovsky
>>>> http://alex-verkhovsky.blogspot.com/
>>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>>>
>>>>
>>>> _______________________________________________
>>>> Cruisecontrolrb-developers mailing list
>>>> [hidden email]
>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>
>>>>
>>> _______________________________________________
>>> Cruisecontrolrb-developers mailing list
>>> [hidden email]
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> [hidden email]
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Chad Woolley
Hmm.  I think Alexey may be right.  Why don't we just continue
vendoring everything, so it is completely self-contained and works out
of the box?  That solves many problems, and I don't see that many
practical problems to NOT using Bundler.  It only really impacts
people hacking on CCRB and wishing to change dependencies, which
should be a very small subset of people who should be able to deal
with vendored gems vs. bundler.

On Wed, May 18, 2011 at 4:33 PM, Brian Guthrie
<[hidden email]> wrote:

> If you specify a dependency on a binary gem, and attempt to lock your
> project to that gem, Bundler will lock the version that's valid for
> your current platform but not every conceivable platform. I consider
> this a major flaw in their locking model, but I believe this may get
> fixed in 1.1. I'll give it a shot in Windows today if I get the
> chance. If everything looks okay, I'll try checking in the lockfile.
>
> Brian
>
> On Thu, May 19, 2011 at 8:31 AM, Chad Woolley <[hidden email]> wrote:
>> Not checking in Gemfile.lock seems like a bad idea.  This allows
>> unspecified/indirect dependencies to float, which is almost guaranteed
>> to cause breakages as the world moves on.
>>
>> On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie
>> <[hidden email]> wrote:
>>> To the best of my knowledge, we do not have any dependencies on binary
>>> gems at the moment. But even if we did, I don't see why it should be a
>>> problem as long as Windows equivalents for those gems exist. I agree
>>> that there's an expectation that CC.rb should be as widely compatible
>>> as possible. I haven't had a chance to test every platform since the
>>> upgrade, but I'm trying to remain true to the spirit of that goal.
>>>
>>> But I don't see any good reason for the expectation that a Windows
>>> user should be able to check out _the source code_ and immediately run
>>> it. If they check out the source code, they can bundle install like
>>> any other Ruby developer. If they install it as a gem, then let gem
>>> dependencies be handled and installed as per normal. Either case would
>>> handle binary gems just fine.
>>>
>>> But if they just want a dependency-free _binary download_, there's no
>>> reason why we can't package a zipfile that includes all dependencies
>>> (using bundle install --deployment, for example) and make that
>>> available. Such an artifact should be the output of a potential
>>> Windows release build.
>>>
>>> You may have noticed that I haven't checked in a Gemfile.lock either.
>>> In case you were wondering why, it's because the last time I tried to
>>> use Bundler on a cross-platform project (fairly recently--six months
>>> ago or so) it failed to lock down dependencies in a platform-agnostic
>>> way. This probably isn't an issue now, because there are no binary
>>> gems, and so perhaps we should reconsider. But it would be if there
>>> were.
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <[hidden email]> wrote:
>>>> If we use bundler with packaged gems (which we should, if we aren't),
>>>> that's essentially the same as vendoring them, which is what we did
>>>> before.
>>>>
>>>> Agreed on avoiding use of binary gems.  Are we using any?  If so, we
>>>> should use a non-binary equivalent if at all possible.
>>>>
>>>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
>>>> <[hidden email]> wrote:
>>>>> I do have a rather strong opinion that it should not use binary gems. This
>>>>> adds a big barrier to entry, especially on Windoze.
>>>>>
>>>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>> Brian:
>>>>>>
>>>>>> I see you added Gemfile to CC.rb. Not having external dependencies, binary
>>>>>> gems etc - this was, in fact, by design.
>>>>>>
>>>>>> The rationale was that this tool should be easy to install for people who
>>>>>> know nothing about Ruby (because it was used on non-Ruby gigs; probably
>>>>>> still is). Therefore, it should only require Ruby and nothing else (not even
>>>>>> rubygems). Everything else is vendored.
>>>>>>
>>>>>> I have a tentative (i.e., not extremely convinced) opinion that it better
>>>>>> remain this way.
>>>>>>
>>>>>> --Alex
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Alexey Verkhovsky
>>>>> http://alex-verkhovsky.blogspot.com/
>>>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Cruisecontrolrb-developers mailing list
>>>>> [hidden email]
>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Cruisecontrolrb-developers mailing list
>>>> [hidden email]
>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>
>>> _______________________________________________
>>> Cruisecontrolrb-developers mailing list
>>> [hidden email]
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> [hidden email]
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Brian Guthrie-3
Vendoring gems doesn't really solve the multi-platform binary problem,
which we'd have to hack in special code to fix, as I understand it
(require "#{RUBY_PLATFORM}/binary_gem"). I'm not worried about gem
dependencies floating a little bit; our Gemfile is fairly conservative
in its versioning, and we have reasonably comprehensive tests. And
anyway, none of this is a problem if we don't have binaries; you were
right about the lockfile, and I'll check it in if I can. (Another
thing I've seen tried is checking in Gemfile.windows, which gets
copied over to become the main lockfile on demand.)

Unless it really is a terrible idea, I'd prefer to continue to use
Bundler and vendor everything on demand for things that need it, like
self-contained releases. Otherwise the existing infrastructure is
pretty capable of resolving dependencies.

CC.rb is an open source project, and making it easy for people to
contribute is important. I'd also like us to follow community norms
where possible. Managing gems has dramatically improved since CC.rb
was written, and what made sense in 2007 may not make sense now.
Relying on Bundler to manage dependencies helps us achieve that goal,
makes some tasks easier, and costs us very little.

Brian

On Thu, May 19, 2011 at 10:02 AM, Chad Woolley <[hidden email]> wrote:

> Hmm.  I think Alexey may be right.  Why don't we just continue
> vendoring everything, so it is completely self-contained and works out
> of the box?  That solves many problems, and I don't see that many
> practical problems to NOT using Bundler.  It only really impacts
> people hacking on CCRB and wishing to change dependencies, which
> should be a very small subset of people who should be able to deal
> with vendored gems vs. bundler.
>
> On Wed, May 18, 2011 at 4:33 PM, Brian Guthrie
> <[hidden email]> wrote:
>> If you specify a dependency on a binary gem, and attempt to lock your
>> project to that gem, Bundler will lock the version that's valid for
>> your current platform but not every conceivable platform. I consider
>> this a major flaw in their locking model, but I believe this may get
>> fixed in 1.1. I'll give it a shot in Windows today if I get the
>> chance. If everything looks okay, I'll try checking in the lockfile.
>>
>> Brian
>>
>> On Thu, May 19, 2011 at 8:31 AM, Chad Woolley <[hidden email]> wrote:
>>> Not checking in Gemfile.lock seems like a bad idea.  This allows
>>> unspecified/indirect dependencies to float, which is almost guaranteed
>>> to cause breakages as the world moves on.
>>>
>>> On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie
>>> <[hidden email]> wrote:
>>>> To the best of my knowledge, we do not have any dependencies on binary
>>>> gems at the moment. But even if we did, I don't see why it should be a
>>>> problem as long as Windows equivalents for those gems exist. I agree
>>>> that there's an expectation that CC.rb should be as widely compatible
>>>> as possible. I haven't had a chance to test every platform since the
>>>> upgrade, but I'm trying to remain true to the spirit of that goal.
>>>>
>>>> But I don't see any good reason for the expectation that a Windows
>>>> user should be able to check out _the source code_ and immediately run
>>>> it. If they check out the source code, they can bundle install like
>>>> any other Ruby developer. If they install it as a gem, then let gem
>>>> dependencies be handled and installed as per normal. Either case would
>>>> handle binary gems just fine.
>>>>
>>>> But if they just want a dependency-free _binary download_, there's no
>>>> reason why we can't package a zipfile that includes all dependencies
>>>> (using bundle install --deployment, for example) and make that
>>>> available. Such an artifact should be the output of a potential
>>>> Windows release build.
>>>>
>>>> You may have noticed that I haven't checked in a Gemfile.lock either.
>>>> In case you were wondering why, it's because the last time I tried to
>>>> use Bundler on a cross-platform project (fairly recently--six months
>>>> ago or so) it failed to lock down dependencies in a platform-agnostic
>>>> way. This probably isn't an issue now, because there are no binary
>>>> gems, and so perhaps we should reconsider. But it would be if there
>>>> were.
>>>>
>>>> Cheers,
>>>>
>>>> Brian
>>>>
>>>> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <[hidden email]> wrote:
>>>>> If we use bundler with packaged gems (which we should, if we aren't),
>>>>> that's essentially the same as vendoring them, which is what we did
>>>>> before.
>>>>>
>>>>> Agreed on avoiding use of binary gems.  Are we using any?  If so, we
>>>>> should use a non-binary equivalent if at all possible.
>>>>>
>>>>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
>>>>> <[hidden email]> wrote:
>>>>>> I do have a rather strong opinion that it should not use binary gems. This
>>>>>> adds a big barrier to entry, especially on Windoze.
>>>>>>
>>>>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>>>>>> <[hidden email]> wrote:
>>>>>>>
>>>>>>> Brian:
>>>>>>>
>>>>>>> I see you added Gemfile to CC.rb. Not having external dependencies, binary
>>>>>>> gems etc - this was, in fact, by design.
>>>>>>>
>>>>>>> The rationale was that this tool should be easy to install for people who
>>>>>>> know nothing about Ruby (because it was used on non-Ruby gigs; probably
>>>>>>> still is). Therefore, it should only require Ruby and nothing else (not even
>>>>>>> rubygems). Everything else is vendored.
>>>>>>>
>>>>>>> I have a tentative (i.e., not extremely convinced) opinion that it better
>>>>>>> remain this way.
>>>>>>>
>>>>>>> --Alex
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alexey Verkhovsky
>>>>>> http://alex-verkhovsky.blogspot.com/
>>>>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Cruisecontrolrb-developers mailing list
>>>>>> [hidden email]
>>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Cruisecontrolrb-developers mailing list
>>>>> [hidden email]
>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>
>>>> _______________________________________________
>>>> Cruisecontrolrb-developers mailing list
>>>> [hidden email]
>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>
>>> _______________________________________________
>>> Cruisecontrolrb-developers mailing list
>>> [hidden email]
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> [hidden email]
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Chad Woolley
"I'd prefer to continue to use Bundler and vendor everything on demand
for things that need it, like self-contained releases." - not positive
what that means, but it sounds like it could be good :)

Also, the Gemfile.windows sounds like a good alternative, especially
if there is a self-contained release for windows users (and a separate
one for unix users if they must differ) so end users don't have to
think about gemfiles at all.

Not as easy as just checking out source, but I can see the benefit of
sticking with standards, and Bundler is definitely the standard now.

On Wed, May 18, 2011 at 5:54 PM, Brian Guthrie
<[hidden email]> wrote:

> Vendoring gems doesn't really solve the multi-platform binary problem,
> which we'd have to hack in special code to fix, as I understand it
> (require "#{RUBY_PLATFORM}/binary_gem"). I'm not worried about gem
> dependencies floating a little bit; our Gemfile is fairly conservative
> in its versioning, and we have reasonably comprehensive tests. And
> anyway, none of this is a problem if we don't have binaries; you were
> right about the lockfile, and I'll check it in if I can. (Another
> thing I've seen tried is checking in Gemfile.windows, which gets
> copied over to become the main lockfile on demand.)
>
> Unless it really is a terrible idea, I'd prefer to continue to use
> Bundler and vendor everything on demand for things that need it, like
> self-contained releases. Otherwise the existing infrastructure is
> pretty capable of resolving dependencies.
>
> CC.rb is an open source project, and making it easy for people to
> contribute is important. I'd also like us to follow community norms
> where possible. Managing gems has dramatically improved since CC.rb
> was written, and what made sense in 2007 may not make sense now.
> Relying on Bundler to manage dependencies helps us achieve that goal,
> makes some tasks easier, and costs us very little.
>
> Brian
>
> On Thu, May 19, 2011 at 10:02 AM, Chad Woolley <[hidden email]> wrote:
>> Hmm.  I think Alexey may be right.  Why don't we just continue
>> vendoring everything, so it is completely self-contained and works out
>> of the box?  That solves many problems, and I don't see that many
>> practical problems to NOT using Bundler.  It only really impacts
>> people hacking on CCRB and wishing to change dependencies, which
>> should be a very small subset of people who should be able to deal
>> with vendored gems vs. bundler.
>>
>> On Wed, May 18, 2011 at 4:33 PM, Brian Guthrie
>> <[hidden email]> wrote:
>>> If you specify a dependency on a binary gem, and attempt to lock your
>>> project to that gem, Bundler will lock the version that's valid for
>>> your current platform but not every conceivable platform. I consider
>>> this a major flaw in their locking model, but I believe this may get
>>> fixed in 1.1. I'll give it a shot in Windows today if I get the
>>> chance. If everything looks okay, I'll try checking in the lockfile.
>>>
>>> Brian
>>>
>>> On Thu, May 19, 2011 at 8:31 AM, Chad Woolley <[hidden email]> wrote:
>>>> Not checking in Gemfile.lock seems like a bad idea.  This allows
>>>> unspecified/indirect dependencies to float, which is almost guaranteed
>>>> to cause breakages as the world moves on.
>>>>
>>>> On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie
>>>> <[hidden email]> wrote:
>>>>> To the best of my knowledge, we do not have any dependencies on binary
>>>>> gems at the moment. But even if we did, I don't see why it should be a
>>>>> problem as long as Windows equivalents for those gems exist. I agree
>>>>> that there's an expectation that CC.rb should be as widely compatible
>>>>> as possible. I haven't had a chance to test every platform since the
>>>>> upgrade, but I'm trying to remain true to the spirit of that goal.
>>>>>
>>>>> But I don't see any good reason for the expectation that a Windows
>>>>> user should be able to check out _the source code_ and immediately run
>>>>> it. If they check out the source code, they can bundle install like
>>>>> any other Ruby developer. If they install it as a gem, then let gem
>>>>> dependencies be handled and installed as per normal. Either case would
>>>>> handle binary gems just fine.
>>>>>
>>>>> But if they just want a dependency-free _binary download_, there's no
>>>>> reason why we can't package a zipfile that includes all dependencies
>>>>> (using bundle install --deployment, for example) and make that
>>>>> available. Such an artifact should be the output of a potential
>>>>> Windows release build.
>>>>>
>>>>> You may have noticed that I haven't checked in a Gemfile.lock either.
>>>>> In case you were wondering why, it's because the last time I tried to
>>>>> use Bundler on a cross-platform project (fairly recently--six months
>>>>> ago or so) it failed to lock down dependencies in a platform-agnostic
>>>>> way. This probably isn't an issue now, because there are no binary
>>>>> gems, and so perhaps we should reconsider. But it would be if there
>>>>> were.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Brian
>>>>>
>>>>> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <[hidden email]> wrote:
>>>>>> If we use bundler with packaged gems (which we should, if we aren't),
>>>>>> that's essentially the same as vendoring them, which is what we did
>>>>>> before.
>>>>>>
>>>>>> Agreed on avoiding use of binary gems.  Are we using any?  If so, we
>>>>>> should use a non-binary equivalent if at all possible.
>>>>>>
>>>>>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
>>>>>> <[hidden email]> wrote:
>>>>>>> I do have a rather strong opinion that it should not use binary gems. This
>>>>>>> adds a big barrier to entry, especially on Windoze.
>>>>>>>
>>>>>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>>>>>>> <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Brian:
>>>>>>>>
>>>>>>>> I see you added Gemfile to CC.rb. Not having external dependencies, binary
>>>>>>>> gems etc - this was, in fact, by design.
>>>>>>>>
>>>>>>>> The rationale was that this tool should be easy to install for people who
>>>>>>>> know nothing about Ruby (because it was used on non-Ruby gigs; probably
>>>>>>>> still is). Therefore, it should only require Ruby and nothing else (not even
>>>>>>>> rubygems). Everything else is vendored.
>>>>>>>>
>>>>>>>> I have a tentative (i.e., not extremely convinced) opinion that it better
>>>>>>>> remain this way.
>>>>>>>>
>>>>>>>> --Alex
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Alexey Verkhovsky
>>>>>>> http://alex-verkhovsky.blogspot.com/
>>>>>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Cruisecontrolrb-developers mailing list
>>>>>>> [hidden email]
>>>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Cruisecontrolrb-developers mailing list
>>>>>> [hidden email]
>>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>>
>>>>> _______________________________________________
>>>>> Cruisecontrolrb-developers mailing list
>>>>> [hidden email]
>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>
>>>> _______________________________________________
>>>> Cruisecontrolrb-developers mailing list
>>>> [hidden email]
>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>
>>> _______________________________________________
>>> Cruisecontrolrb-developers mailing list
>>> [hidden email]
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> [hidden email]
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Alexey Verkhovsky-2
In reply to this post by Brian Guthrie-3
On Wed, May 18, 2011 at 3:47 PM, Brian Guthrie <[hidden email]> wrote:
To the best of my knowledge, we do not have any dependencies on binary
gems at the moment.

nokogiri

Not all CC.rb users are Ruby developers. At least, this used to be the case when I kept awareness of such things.


_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Brian Guthrie-3
In reply to this post by Chad Woolley
On Thu, May 19, 2011 at 12:24 PM, Chad Woolley <[hidden email]> wrote:
> "I'd prefer to continue to use Bundler and vendor everything on demand
> for things that need it, like self-contained releases." - not positive
> what that means, but it sounds like it could be good :)

task :release => :test
  `bundle install --deployment`
  `gem package`
  `gem push ccrb-#{RUBY-PLATFORM}.gem`
end

Something like that. Replace gem package with tar and zip for non-gem
Linux and Windows releases respectively if needed.

I've looked into binary gems. Nokogiri has crept into the gemfile via
Mechanize (which I believe exists for the performance build, which I'm
not currently maintaining - any volunteers?). It can be eliminated as
a dependency by removing mechanize and adding Builder explicitly as a
dependency. This still leaves many failing tests, which I haven't
begun to look into. Do we have some idea of how many Windows users
CC.rb has?

Apparently there is now a way to build many C-based gems in Windows
(see https://github.com/oneclick/rubyinstaller) and so one could
conceivably run a Windows release task on a Windows box that built the
necessary binaries on demand and automatically uploaded them to the
main CC.rb site.

Cheers,

Brian
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Alexey Verkhovsky-2
On Thu, May 19, 2011 at 1:50 PM, Brian Guthrie <[hidden email]> wrote:
Do we have some idea of how many Windows users CC.rb has?

Not many.
 
Apparently there is now a way to build many C-based gems in Windows
(see https://github.com/oneclick/rubyinstaller) and so one could
conceivably run a Windows release task on a Windows box that built the
necessary binaries on demand and automatically uploaded them to the
main CC.rb site.

Would be a great idea for a *very seriously* supported project. For an open-source project that sees a bit of ongoing development every once in a while, you don't want to maintain complex infrastructure of this sort. :)

_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Sidu Ponnappa-2
Would it be fair to support Windows only via JRuby? That would make
life much easier for you.

Best,
Sidu.
http://c42.in

On 20 May 2011 01:52, Alexey Verkhovsky <[hidden email]> wrote:

> On Thu, May 19, 2011 at 1:50 PM, Brian Guthrie <[hidden email]>
> wrote:
>>
>> Do we have some idea of how many Windows users CC.rb has?
>
> Not many.
>
>>
>> Apparently there is now a way to build many C-based gems in Windows
>> (see https://github.com/oneclick/rubyinstaller) and so one could
>> conceivably run a Windows release task on a Windows box that built the
>> necessary binaries on demand and automatically uploaded them to the
>> main CC.rb site.
>
> Would be a great idea for a *very seriously* supported project. For an
> open-source project that sees a bit of ongoing development every once in a
> while, you don't want to maintain complex infrastructure of this sort. :)
>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Brian Guthrie-3
In reply to this post by Alexey Verkhovsky-2
On Fri, May 20, 2011 at 6:22 AM, Alexey Verkhovsky
<[hidden email]> wrote:

> On Thu, May 19, 2011 at 1:50 PM, Brian Guthrie <[hidden email]>
> wrote:
>>
>> Do we have some idea of how many Windows users CC.rb has?
>
> Not many.
>
>>
>> Apparently there is now a way to build many C-based gems in Windows
>> (see https://github.com/oneclick/rubyinstaller) and so one could
>> conceivably run a Windows release task on a Windows box that built the
>> necessary binaries on demand and automatically uploaded them to the
>> main CC.rb site.
>
> Would be a great idea for a *very seriously* supported project. For an
> open-source project that sees a bit of ongoing development every once in a
> while, you don't want to maintain complex infrastructure of this sort. :)

That's a good point, although I hasten to add that I wasn't
_seriously_ planning on building binaries on Windows; I just thought
it was interesting that it existed at all. :) I'll plan on ridding the
Gemfile of Nokogiri the next chance I get, and get Windows tests
running properly, and that should in principle eliminate the need for
a separate build box.

Cheers,

Brian
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers