Subject: Re: Getting ready for release 0.9.0 - msg#00021

Previous Message by Date: click to view message preview

Re: Getting ready for release 0.9.0

On 6/7/06, Jim Weirich <jim-Fxty1mrVU9GlFc2d6oM/ew@xxxxxxxxxxxxxxxx> wrote: > > I pondered long and hard over the datadir issue [snip] > > Any questions? What is "the datadir issue"? I poked around the RubyGems site and didn't see anything about it there. Also tried "gem environment" and didn't see any mention of it. Tried a "grep -ri datadir *" in lib/ruby/site_ruby/1.8 but didn't find anything. Google found me a few mailing list postings, but they presumed I already knew what the issue was. Thanks, ---John

Next Message by Date: click to view message preview

Re: Getting ready for release 0.9.0

On Wed, Jun 07, 2006 at 03:57:17PM -0400, Jim Weirich wrote: > I pondered long and hard over the datadir issue and finally decide to > take a minimalist approach verify similar to Maruicio's first suggestion > in http://tinyurl.com/b7yo9. I am suggesting that people use > Config.datadir(package_name) to locate their data directory. In the > absence of RubyGems, this will just resolve to > File.join(Config::CONFIG['datadir'], package_name). If RubyGems is > present, it will locate the 'data' directory in the corresponding > versioned gem area. A few unprocessed thoughts: (a) the documentation will have to insist on the necessity of putting the data under data/myproject and using File.join(Config.datadir(package_name), "myproject") The extra subdirectory is needed because installing stuff right under CONFIG["datadir"] (with setup.rb or equivalent tools) would not be acceptable (too prone to name clashes). In other words, while something like File.open(Config.datadir(package_name) + "foo.dat"){|f| ... } would be OK when installed with RubyGems, it'd lead to problems with setup.rb and friends. This is obvious if one reads the non-RubyGems-enabled definition of Config.datadir, but people releasing primarily in RubyGems format might never see it. This is again about promoting good practices that make sw. installable and usable also without RubyGems. (b) Can the argument to Config.datadir be used to access data from another package? At that point we can run into versioning problems: given Config.datadir("foo")... * whose datadir should be chosen if there are several versions of foo installed? the latest's? If so, a package that is working fine might break when a new version of a seemingly unrelated package is installed. (Note that this does not differ from the current situation with RubyGems' Kernel#require as far as code, as opposed to data, is concerned) This can be addressed in many ways, but none seems to solve everything satisfactorily: * adding explicit version info would work, but it's probably too verbose (you'd do it as Config.datadir("foo", DATAVERSION) so as to not be forced to change lots of lines if the specific version changes) * if the package depends on the one containing the data, the exact version can be inferred from the RubyGems spec. *However*, "data dependencies" might not always result in actual dependencies: it is (or rather, it should be) possible to have a package recommend/suggest the installation of another one. (c) Optional dependencies and "data discovery": code using CONFIG["datadir"] could run Find.find() on that dir to search for stuff. Should that be supported at all? (my tentative answer is: not with Config.datadir(package_name), if at all) What about trying to see if data from a known package is available? Config.datadir("someoptionaldep") could return nil or an empty/nonexistent dir when someoptionaldep is not available. (d) with setup.rb, different packages could be providing the same data (as if we had a normal name clash, but done deliberately and hopefully resulting in everything working fine); this becomes impossible with Config.datadir("foo") I think that's a good thing. a-c deserve some further reflection in my opinion. As for (d), I think that choosing *not* to support it is the right choice. > This has several real advantages: > > * It is compatible with setup.rb (where the data directory defaults to > 'data'). A project can use a single directory structure to satisfy both > the gem and setup.rb packaging requirements. > > * The application remains unaware whether it is running as a gem or a > directly installed app. This is very important. The application will indeed work, but (a) applies. > * It retains versioned data directories so that we don't break the > multi-version nature of RubyGems. (b) I'll try to spare some brain cycles for this, but these are the first things that come to mind. -- Mauricio Fernandez - http://eigenclass.org - singular Ruby

Previous Message by Thread: click to view message preview

Re: Getting ready for release 0.9.0

On 6/7/06, Jim Weirich <jim-Fxty1mrVU9GlFc2d6oM/ew@xxxxxxxxxxxxxxxx> wrote: > > I pondered long and hard over the datadir issue [snip] > > Any questions? What is "the datadir issue"? I poked around the RubyGems site and didn't see anything about it there. Also tried "gem environment" and didn't see any mention of it. Tried a "grep -ri datadir *" in lib/ruby/site_ruby/1.8 but didn't find anything. Google found me a few mailing list postings, but they presumed I already knew what the issue was. Thanks, ---John

Next Message by Thread: click to view message preview

Re: Getting ready for release 0.9.0

It's not hard to just store data in the ruby lib directory. One can use caller to find a path relative to a library, as in: def lib_filename( resource, displace=0 ) caller[displace] =~ /^((\w:){0,1}.*?):(\d+)(:?(.*))$/ dirname = File.dirname( $1 ) File.join( dirname, resource ) end Given: ..../mylibdir/my_lib.rb ..../mylibdir/resources/icon.gif In my_lib.rb, one could use lib_filename to find the path to the icon: my_icon_path = lib_filename( 'resources/icon.gif' ) The displace argument is there so that nested functions can use it. In ruby-web, there is a Web::send_lib_file( relative_filename ) which uses the displacement. Cheers, Patrick On Jun 7, 2006, at 5:45 PM, Lyle Johnson wrote: > On 6/7/06, John Gabriele <jmg3000-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx> > wrote: > >> What is "the datadir issue"? > > This refers to the problem of how to deal with application data in > Gems. For example, if your GUI application requires a bunch of image > files that are loaded at run time, where do you load them from? What > if different versions of your application require different sets of > image files? > > In the same way you just type: > > require 'some_library' > > and RubyGems magically finds the right code, in the latest gem, it > would be useful to be able to do this: > > icons_dir = File.join(Config.datadir('my_app'), "icons") > > and trust that it will find your application's data files (and, the > right versions of those files). > > Hope this helps, > > Lyle > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers-GrnCvJ7WPxnNLxjTenLetw@xxxxxxxxxxxxxxxx > http://rubyforge.org/mailman/listinfo/rubygems-developers