On Sat, Aug 7, 2021 at 1:10 PM sebb <seb...@gmail.com> wrote:
>
> On Sat, 7 Aug 2021 at 17:42, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > On Sat, Aug 7, 2021 at 11:46 AM sebb <seb...@gmail.com> wrote:
> > >
> > > On Sat, 7 Aug 2021 at 16:28, Sam Ruby <ru...@intertwingly.net> wrote:
> > > >
> > > > The 'gem' lines with path values in Gemfiles are effectively a way to
> > > > add another part of the source tree to the ruby lib path.
> > >
> > > But is the Gem packaging code still needed for Whimsy?
> >
> > Indeed, there is no need to package the gem.  There may be a few rare
> > cases where it was useful for bootstrapping (setupmymac, docker), but
> > those can be addressed by other (and frankly better) ways.
> >
> > > I've created a branch to work on this.
> > > It mostly works, but it looks like some code which was previously
> > > pulled in by the Whimsy gem needs to be explicitly referenced.
> >
> > That's what the 'gem' lines with path values in Gemfiles do.  Those
> > lines either need to be restored, or another way to achieve this needs
> > to be created.
>
> The lines I removed from the Gemfiles referred to the 'whimsy-asf' gem.
> Does that not need to exist?

It does not need to exist as a published or installed gem.  Take a
look at the Gemfile.lock file that is produced by bundle
install/update.

> AFAICT the branch I created does work; it is only Travis that has problems.

I'm not so sure about that.  Anything that references bundler will
cause bundle to rewrite your ruby library path.  You probably can get
CGis to avoid referencing bundler, but I doubt that you can get
passenger applications to do so.  And Travis probably does so too, by
default.

It is probably best to continue with having all dependencies in the
Gemfile, including path references to the lib directory.

- Sam Ruby

Reply via email to