[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Wisdom of including Rakefile in releases

Trans

11/30/2006 8:16:00 PM

I was poking around in the /usr/lib/ruby/gems directory today and
noticed that many of the installed libs/apps include Rakefiles in them.
Now, I was thinking about this very thing in the distribution of my own
packages. I'm not so sure that's a good idea. It's probably best not to
include the build scripts in the release distribution since it's of no
value there. In fact it could be dangerous even. Running a rake task
from an installation could expect file system locations only the
developer is setup-for.

What do others think about this?

T.
10 Answers

Trans

11/30/2006 9:57:00 PM

0


Jason Roelofs wrote:
> Rakefiles allow users to run the tests for themselves, to understand how a
> library is put together, etc. The only thing that can go wrong is that the
> stuff doesn't work (unless you're grabbing very untrustworthy packages, but
> assumptions have to be made somewhere). Not to mention, having the Rakefile
> there allows other people to properly make changes to a library if / when
> they need to.
>
> I don't see anything bad with including said Rakefiles. Do you have any
> specific worries?

Yes. For instance I have a little backup task that I sometimes use to
make an archival copy of my project. I'll use it when I'm about to try
out another build task that could potentially screw my project up if I
made some mistake (rarely used but I try to be cautious). The backup
gets saved in a special directory just above the project directory
which obviously won't exist on someone elses system in their gem
folder.

Another example is a task for uploading the project's website to a
host. I'm not inclined to distribute my projects website with the dist.
release and I don't expect anyone to be using that task buyt me.

Granted these tasks will generally just fail rather then do any harm,
but since they won't work it indicates to me they should not be
distributed in the first place. after all, a dist. realease is inteded
for usage only. If one wishes to work with the code they should pull
down a copy of the repository. But then again , maybe that distinction
isn't such a good one, in particluar for open source software.

T.

Ross Bamford

12/1/2006 1:25:00 AM

0

On Thu, 30 Nov 2006 21:57:10 -0000, Trans <transfire@gmail.com> wrote:

>
> Jason Roelofs wrote:
>> Rakefiles allow users to run the tests for themselves, to understand
>> how a
>> library is put together, etc. The only thing that can go wrong is that
>> the
>> stuff doesn't work (unless you're grabbing very untrustworthy packages,
>> but
>> assumptions have to be made somewhere). Not to mention, having the
>> Rakefile
>> there allows other people to properly make changes to a library if /
>> when
>> they need to.
>>
>> I don't see anything bad with including said Rakefiles. Do you have any
>> specific worries?
>
> Yes. For instance I have a little backup task that I sometimes use to
> make an archival copy of my project. I'll use it when I'm about to try
> out another build task that could potentially screw my project up if I
> made some mistake (rarely used but I try to be cautious). The backup
> gets saved in a special directory just above the project directory
> which obviously won't exist on someone elses system in their gem
> folder.
>
> Another example is a task for uploading the project's website to a
> host. I'm not inclined to distribute my projects website with the dist.
> release and I don't expect anyone to be using that task buyt me.
>

The way I've come to approach this is to have a local rakefile in which I
define tasks for stuff like publishing the website and taking backups,
based around my standard project layout and tasks, which I then either
require (conditionally) from the project-specific rakefile, or require as
I need it with e.g.:

rake -r ~/.local_rake_tasks.rb some_task other_task

--
Ross Bamford - rosco@roscopeco.remove.co.uk

Vassilis Rizopoulos

12/1/2006 10:03:00 AM

0

Ross Bamford wrote:
> On Thu, 30 Nov 2006 21:57:10 -0000, Trans <transfire@gmail.com>
> wrote:
>
>>
>> Jason Roelofs wrote:
>>> Rakefiles allow users to run the tests for themselves, to
>>> understand how a library is put together, etc. The only thing
>>> that can go wrong is that the stuff doesn't work (unless you're
>>> grabbing very untrustworthy packages, but assumptions have to be
>>> made somewhere). Not to mention, having the Rakefile there allows
>>> other people to properly make changes to a library if / when they
>>> need to.
>>>
>>> I don't see anything bad with including said Rakefiles. Do you
>>> have any specific worries?
>>
>> Yes. For instance I have a little backup task that I sometimes use
>> to make an archival copy of my project. I'll use it when I'm about
>> to try out another build task that could potentially screw my
>> project up if I made some mistake (rarely used but I try to be
>> cautious). The backup gets saved in a special directory just above
>> the project directory which obviously won't exist on someone elses
>> system in their gem folder.
>>
>> Another example is a task for uploading the project's website to a
>> host. I'm not inclined to distribute my projects website with the
>> dist. release and I don't expect anyone to be using that task buyt
>> me.
>>
>
> The way I've come to approach this is to have a local rakefile in
> which I define tasks for stuff like publishing the website and taking
> backups, based around my standard project layout and tasks, which I
> then either require (conditionally) from the project-specific
> rakefile, or require as I need it with e.g.:
>
> rake -r ~/.local_rake_tasks.rb some_task other_task
>
> --Ross Bamford - rosco@roscopeco.remove.co.uk
I am all for including the rakefiles in the gems. Especially if the
tests are there as well. It just makes life easier when there are
problems: you have your user run the tests and sent you that log back as
well=> more data for bug hunting.

You can even require the "local" rake tasks in the main rakefile and
rescue the load failure so that your user doesn't even realise there
might have been more there and you don't have to require them by hand
all the time.
Cheers,
V.-

--
http://www.braveworl...

Hans Fugal

12/1/2006 3:15:00 PM

0

Trans wrote:
> I was poking around in the /usr/lib/ruby/gems directory today and
> noticed that many of the installed libs/apps include Rakefiles in them.
> Now, I was thinking about this very thing in the distribution of my own
> packages. I'm not so sure that's a good idea. It's probably best not to
> include the build scripts in the release distribution since it's of no
> value there. In fact it could be dangerous even. Running a rake task
> from an installation could expect file system locations only the
> developer is setup-for.
>
> What do others think about this?

It's fully within the unix tradition of including the whole source in
release tarballs. It's true that unix 'make install' doesn't usually
install the makefile somewhere, though. I wouldn't worry about it, in
any case. If your rakefile is dangerous then you might want to rethink
it or put some sanity checks in. If you're worried about Joe Clueless
running a dangerous non-default rake target in some obscure directory...

Trans

12/4/2006 12:22:00 PM

0


Hans Fugal wrote:

> It's fully within the unix tradition of including the whole source in
> release tarballs. It's true that unix 'make install' doesn't usually
> install the makefile somewhere, though. I wouldn't worry about it, in
> any case. If your rakefile is dangerous then you might want to rethink
> it or put some sanity checks in. If you're worried about Joe Clueless
> running a dangerous non-default rake target in some obscure directory...

Good advice. I'll remove some of the default settings and mkdir_p's and
raise errors in their place. Then not worry about it. Thanks.

Slightly aside, where do others store their project websites?

T.

Trans

12/4/2006 3:40:00 PM

0


Jason Roelofs wrote:
> rubyforge.org <-- All ruby / rails releases normally go here
>
> sourceforge.net / freshmeat.net <-- everything else.
>
> These places will give you a small space for a project-specific website as
> well.

By bad. I should have been more clear. I meant where do you store the
files locally? Eg. in your projects repository under a web/ directory,
or in some seprate location? I'm curious if there's some generally
accepted convention. Recently I reversed the way I had been handling
this and rather then store the website in the repository I now store
the repository in the website. Basically:

myproject/
index.html
repo/
branches/
tags/
trunk/

I like this layout b/c it makes the source repository an integrated
part of the site --I can just serve the whole directory up. On the down
side however the web files aren't under version control.

T.

Austin Ziegler

12/4/2006 4:10:00 PM

0

On 11/30/06, Trans <transfire@gmail.com> wrote:
> I was poking around in the /usr/lib/ruby/gems directory today and
> noticed that many of the installed libs/apps include Rakefiles in them.
> Now, I was thinking about this very thing in the distribution of my own
> packages. I'm not so sure that's a good idea. It's probably best not to
> include the build scripts in the release distribution since it's of no
> value there. In fact it could be dangerous even. Running a rake task
> from an installation could expect file system locations only the
> developer is setup-for.
>
> What do others think about this?

As I start to get back into supporting my projects, you will see more
"support" files. If they're in my source control, they'll end up in my
released package. I used to release without this, but was convinced
after a discussion about idempotence of release packages. This will
make life easier for downstream repackagers.

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halo...
* austin@halostatue.ca * http://www.halo...feed/
* austin@zieglers.ca

Eric Hodel

12/4/2006 6:54:00 PM

0

On Nov 30, 2006, at 12:15 , Trans wrote:

> I was poking around in the /usr/lib/ruby/gems directory today and
> noticed that many of the installed libs/apps include Rakefiles in
> them.
> Now, I was thinking about this very thing in the distribution of my
> own
> packages. I'm not so sure that's a good idea. It's probably best
> not to
> include the build scripts in the release distribution since it's of no
> value there. In fact it could be dangerous even. Running a rake task
> from an installation could expect file system locations only the
> developer is setup-for.
>
> What do others think about this?

How am I supposed to run the tests to figure out if your gem works
when I come across a problem with it if there's no Rakefile?

--
Eric Hodel - drbrain@segment7.net - http://blog.se...

I LIT YOUR GEM ON FIRE!

Devin Mullins

12/5/2006 1:20:00 AM

0

Eric Hodel wrote:
> On Nov 30, 2006, at 12:15 , Trans wrote:
>
>> I was poking around in the /usr/lib/ruby/gems directory today and
>> noticed that many of the installed libs/apps include Rakefiles in them.
>> ...
>> What do others think about this?
>
> How am I supposed to run the tests to figure out if your gem works when
> I come across a problem with it if there's no Rakefile?

What? I'm supposed to write tests?

Trans

12/5/2006 3:18:00 AM

0


Eric Hodel wrote:

> How am I supposed to run the tests to figure out if your gem works
> when I come across a problem with it if there's no Rakefile?

Thre's always

setup.rb test

But I take your point.

T.