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?
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.
other people to properly make changes to a library if / when they
the project directory which obviously won’t exist on someone elses
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.:
–Ross B. - [email protected]
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.-
there allows other people to properly make changes to a library if /
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 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…
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?
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.
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.
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?