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.
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?
Jason
···
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.
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...
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
···
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.
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?
···
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.
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.
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?
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?
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.:
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.
These places will give you a small space for a project-specific website as
well.
Jason
···
On 12/4/06, Trans <transfire@gmail.com> wrote:
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?
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.:
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.-
···
On Thu, 30 Nov 2006 21:57:10 -0000, Trans <transfire@gmail.com> > wrote:
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:
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.