Warnings re: already initialized constants

[sebb <se...@gmail.com>]

For example: "warning: already initialized constant Net::ProtocRetryError"

The following Ruby code generates the warning on Whimsy (and in my
Docker build):

require 'net/http'
require 'net/smtp'

The same happens if the require order is reversed.

I wondered why the public json scripts only report the error sometimes.
Turns out that the script only requires 'net/smtp' (via require
'mail') if there has been a change that needs to be mailed to the
list.

Whilst the warning is harmless (I think), it can obscure other errors,
so I would like to fix it.

It looks like removing the net-smtp Gem solves the issue.
When tested in Docker, this does not appear to affect the ability to
send emails, so I propose to make the change in Whimsy -- unless I
hear otherwise?

Sebb

Re: Warnings re: already initialized constants

[sebb <se...@gmail.com>]

On Tue, 26 Apr 2022 at 16:48, Matt Sicker <bo...@gmail.com> wrote:
>
> If there's environment drift in Whimsy VM versus Whimsy Docker, could
> we deploy Whimsy as a container instead? Make the Whimsy VM a
> container host, that sort of thing. Decouples our versions of Apache,
> Ruby, etc., from the underlying OS.

I don't think that is the issue here.

> On Tue, Apr 26, 2022 at 10:10 AM sebb <se...@gmail.com> wrote:
> >
> > On Tue, 26 Apr 2022 at 16:03, Sam Ruby <ru...@intertwingly.net> wrote:
> > >
> > > On Tue, Apr 26, 2022 at 10:27 AM sebb <se...@gmail.com> wrote:
> > > >
> > > > On Tue, 26 Apr 2022 at 14:53, Sam Ruby <ru...@intertwingly.net> wrote:
> > > > >
> > > > > On Tue, Apr 26, 2022 at 9:29 AM sebb <se...@gmail.com> wrote:
> > > > > >
> > > > > > There are a lot of older versions of Gems around - maybe time to do a cleanup?
> > > > >
> > > > > It would take a bit of refactoring, but there is code in the Rakefile
> > > > > that might be useful.  On my ubuntu machine, I need to prefix gem
> > > > > install commands with `sudo` and having `rake udpate` iterate through
> > > > > the gemfiles and prompting me many times grew old fast so I added a
> > > > > check to see if Bundler.bundle_path.writable? and if not I would build
> > > > > a single gemfile that collected up all the dependencies.  Having a
> > > > > 'rake gem:clean' or equivalent task that would do this followed
> > > > > immediately by an update might be useful.  The update is required as
> > > > > there are rare cases where different apps use different gems (until
> > > > > recently, active_support required an old version of tzinfo, for
> > > > > example).
> > > >
> > > > I don't think that is the case at present.
> > >
> > > True, but it won't always be the case.
> > >
> > > > I just did a cleanup on the Docker build, and a subsequent update did
> > > > not install anything.
> > > >
> > > > Is a separate task needed?
> > > > Why not just always do a cleanup just before an update?
> > >
> > > Routinely uninstalling a gem that is still needed (like was the case
> > > with the tzinfo gem) will likely cause user visible failures.
> >
> > If it is done just before an update then the time window during which
> > the required gem version is missing should be quite short.
> >
> > But if that is unacceptable I guess it would be possible to parse the
> > versions installed by the update process and work out which others are
> > not needed.
> >
> > > > The update might then introduce new versions, but next time around
> > > > they should be cleaned up.
> > > >
> > > > > Of course, all this will be cleaned up when infra supports Ubuntu
> > > > > 22.04 and we move to whimsy-vm7.
> > > >
> > > > That will result in an initial cleanup, but versions will continue to
> > > > build up over time, so cleanup will still be needed.
> > > >
> > > > > - Sam Ruby
> > >
> > > - Sam Ruby

Re: Warnings re: already initialized constants

[Matt Sicker <bo...@gmail.com>]

If there's environment drift in Whimsy VM versus Whimsy Docker, could
we deploy Whimsy as a container instead? Make the Whimsy VM a
container host, that sort of thing. Decouples our versions of Apache,
Ruby, etc., from the underlying OS.

On Tue, Apr 26, 2022 at 10:10 AM sebb <se...@gmail.com> wrote:
>
> On Tue, 26 Apr 2022 at 16:03, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > On Tue, Apr 26, 2022 at 10:27 AM sebb <se...@gmail.com> wrote:
> > >
> > > On Tue, 26 Apr 2022 at 14:53, Sam Ruby <ru...@intertwingly.net> wrote:
> > > >
> > > > On Tue, Apr 26, 2022 at 9:29 AM sebb <se...@gmail.com> wrote:
> > > > >
> > > > > There are a lot of older versions of Gems around - maybe time to do a cleanup?
> > > >
> > > > It would take a bit of refactoring, but there is code in the Rakefile
> > > > that might be useful.  On my ubuntu machine, I need to prefix gem
> > > > install commands with `sudo` and having `rake udpate` iterate through
> > > > the gemfiles and prompting me many times grew old fast so I added a
> > > > check to see if Bundler.bundle_path.writable? and if not I would build
> > > > a single gemfile that collected up all the dependencies.  Having a
> > > > 'rake gem:clean' or equivalent task that would do this followed
> > > > immediately by an update might be useful.  The update is required as
> > > > there are rare cases where different apps use different gems (until
> > > > recently, active_support required an old version of tzinfo, for
> > > > example).
> > >
> > > I don't think that is the case at present.
> >
> > True, but it won't always be the case.
> >
> > > I just did a cleanup on the Docker build, and a subsequent update did
> > > not install anything.
> > >
> > > Is a separate task needed?
> > > Why not just always do a cleanup just before an update?
> >
> > Routinely uninstalling a gem that is still needed (like was the case
> > with the tzinfo gem) will likely cause user visible failures.
>
> If it is done just before an update then the time window during which
> the required gem version is missing should be quite short.
>
> But if that is unacceptable I guess it would be possible to parse the
> versions installed by the update process and work out which others are
> not needed.
>
> > > The update might then introduce new versions, but next time around
> > > they should be cleaned up.
> > >
> > > > Of course, all this will be cleaned up when infra supports Ubuntu
> > > > 22.04 and we move to whimsy-vm7.
> > >
> > > That will result in an initial cleanup, but versions will continue to
> > > build up over time, so cleanup will still be needed.
> > >
> > > > - Sam Ruby
> >
> > - Sam Ruby

Re: Warnings re: already initialized constants

[sebb <se...@gmail.com>]

On Tue, 26 Apr 2022 at 16:03, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Tue, Apr 26, 2022 at 10:27 AM sebb <se...@gmail.com> wrote:
> >
> > On Tue, 26 Apr 2022 at 14:53, Sam Ruby <ru...@intertwingly.net> wrote:
> > >
> > > On Tue, Apr 26, 2022 at 9:29 AM sebb <se...@gmail.com> wrote:
> > > >
> > > > There are a lot of older versions of Gems around - maybe time to do a cleanup?
> > >
> > > It would take a bit of refactoring, but there is code in the Rakefile
> > > that might be useful.  On my ubuntu machine, I need to prefix gem
> > > install commands with `sudo` and having `rake udpate` iterate through
> > > the gemfiles and prompting me many times grew old fast so I added a
> > > check to see if Bundler.bundle_path.writable? and if not I would build
> > > a single gemfile that collected up all the dependencies.  Having a
> > > 'rake gem:clean' or equivalent task that would do this followed
> > > immediately by an update might be useful.  The update is required as
> > > there are rare cases where different apps use different gems (until
> > > recently, active_support required an old version of tzinfo, for
> > > example).
> >
> > I don't think that is the case at present.
>
> True, but it won't always be the case.
>
> > I just did a cleanup on the Docker build, and a subsequent update did
> > not install anything.
> >
> > Is a separate task needed?
> > Why not just always do a cleanup just before an update?
>
> Routinely uninstalling a gem that is still needed (like was the case
> with the tzinfo gem) will likely cause user visible failures.

If it is done just before an update then the time window during which
the required gem version is missing should be quite short.

But if that is unacceptable I guess it would be possible to parse the
versions installed by the update process and work out which others are
not needed.

> > The update might then introduce new versions, but next time around
> > they should be cleaned up.
> >
> > > Of course, all this will be cleaned up when infra supports Ubuntu
> > > 22.04 and we move to whimsy-vm7.
> >
> > That will result in an initial cleanup, but versions will continue to
> > build up over time, so cleanup will still be needed.
> >
> > > - Sam Ruby
>
> - Sam Ruby

Re: Warnings re: already initialized constants

[Sam Ruby <ru...@intertwingly.net>]

On Tue, Apr 26, 2022 at 10:27 AM sebb <se...@gmail.com> wrote:
>
> On Tue, 26 Apr 2022 at 14:53, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > On Tue, Apr 26, 2022 at 9:29 AM sebb <se...@gmail.com> wrote:
> > >
> > > There are a lot of older versions of Gems around - maybe time to do a cleanup?
> >
> > It would take a bit of refactoring, but there is code in the Rakefile
> > that might be useful.  On my ubuntu machine, I need to prefix gem
> > install commands with `sudo` and having `rake udpate` iterate through
> > the gemfiles and prompting me many times grew old fast so I added a
> > check to see if Bundler.bundle_path.writable? and if not I would build
> > a single gemfile that collected up all the dependencies.  Having a
> > 'rake gem:clean' or equivalent task that would do this followed
> > immediately by an update might be useful.  The update is required as
> > there are rare cases where different apps use different gems (until
> > recently, active_support required an old version of tzinfo, for
> > example).
>
> I don't think that is the case at present.

True, but it won't always be the case.

> I just did a cleanup on the Docker build, and a subsequent update did
> not install anything.
>
> Is a separate task needed?
> Why not just always do a cleanup just before an update?

Routinely uninstalling a gem that is still needed (like was the case
with the tzinfo gem) will likely cause user visible failures.

> The update might then introduce new versions, but next time around
> they should be cleaned up.
>
> > Of course, all this will be cleaned up when infra supports Ubuntu
> > 22.04 and we move to whimsy-vm7.
>
> That will result in an initial cleanup, but versions will continue to
> build up over time, so cleanup will still be needed.
>
> > - Sam Ruby

- Sam Ruby

Re: Warnings re: already initialized constants

[sebb <se...@gmail.com>]

On Tue, 26 Apr 2022 at 14:53, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Tue, Apr 26, 2022 at 9:29 AM sebb <se...@gmail.com> wrote:
> >
> > There are a lot of older versions of Gems around - maybe time to do a cleanup?
>
> It would take a bit of refactoring, but there is code in the Rakefile
> that might be useful.  On my ubuntu machine, I need to prefix gem
> install commands with `sudo` and having `rake udpate` iterate through
> the gemfiles and prompting me many times grew old fast so I added a
> check to see if Bundler.bundle_path.writable? and if not I would build
> a single gemfile that collected up all the dependencies.  Having a
> 'rake gem:clean' or equivalent task that would do this followed
> immediately by an update might be useful.  The update is required as
> there are rare cases where different apps use different gems (until
> recently, active_support required an old version of tzinfo, for
> example).

I don't think that is the case at present.
I just did a cleanup on the Docker build, and a subsequent update did
not install anything.

Is a separate task needed?
Why not just always do a cleanup just before an update?
The update might then introduce new versions, but next time around
they should be cleaned up.

> Of course, all this will be cleaned up when infra supports Ubuntu
> 22.04 and we move to whimsy-vm7.

That will result in an initial cleanup, but versions will continue to
build up over time, so cleanup will still be needed.

> - Sam Ruby

Re: Warnings re: already initialized constants

[Sam Ruby <ru...@intertwingly.net>]

On Tue, Apr 26, 2022 at 9:29 AM sebb <se...@gmail.com> wrote:
>
> There are a lot of older versions of Gems around - maybe time to do a cleanup?

It would take a bit of refactoring, but there is code in the Rakefile
that might be useful.  On my ubuntu machine, I need to prefix gem
install commands with `sudo` and having `rake udpate` iterate through
the gemfiles and prompting me many times grew old fast so I added a
check to see if Bundler.bundle_path.writable? and if not I would build
a single gemfile that collected up all the dependencies.  Having a
'rake gem:clean' or equivalent task that would do this followed
immediately by an update might be useful.  The update is required as
there are rare cases where different apps use different gems (until
recently, active_support required an old version of tzinfo, for
example).

Of course, all this will be cleaned up when infra supports Ubuntu
22.04 and we move to whimsy-vm7.

- Sam Ruby

Re: Warnings re: already initialized constants

[sebb <se...@gmail.com>]

On Tue, 26 Apr 2022 at 14:11, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Tue, Apr 26, 2022 at 8:24 AM sebb <se...@gmail.com> wrote:
> >
> > For example: "warning: already initialized constant Net::ProtocRetryError"
> >
> > The following Ruby code generates the warning on Whimsy (and in my
> > Docker build):
> >
> > require 'net/http'
> > require 'net/smtp'
> >
> > The same happens if the require order is reversed.
> >
> > I wondered why the public json scripts only report the error sometimes.
> > Turns out that the script only requires 'net/smtp' (via require
> > 'mail') if there has been a change that needs to be mailed to the
> > list.
> >
> > Whilst the warning is harmless (I think), it can obscure other errors,
> > so I would like to fix it.
> >
> > It looks like removing the net-smtp Gem solves the issue.
> > When tested in Docker, this does not appear to affect the ability to
> > send emails, so I propose to make the change in Whimsy -- unless I
> > hear otherwise?
>
> If you remove the net-smtp gem from the Gemfile, the require will fail
> with ruby 3.1.2p20.
>
> Perhaps add "unless RUBY_VERSION =~ /^2/" to that line in the Gemfile?

OK, done.

Also I uninstalled the non-default version of net-smtp.

The sample require script no longer generates warnings.

There are a lot of older versions of Gems around - maybe time to do a cleanup?

> > Sebb
>
> - Sam Ruby

Re: Warnings re: already initialized constants

[Sam Ruby <ru...@intertwingly.net>]

On Tue, Apr 26, 2022 at 8:24 AM sebb <se...@gmail.com> wrote:
>
> For example: "warning: already initialized constant Net::ProtocRetryError"
>
> The following Ruby code generates the warning on Whimsy (and in my
> Docker build):
>
> require 'net/http'
> require 'net/smtp'
>
> The same happens if the require order is reversed.
>
> I wondered why the public json scripts only report the error sometimes.
> Turns out that the script only requires 'net/smtp' (via require
> 'mail') if there has been a change that needs to be mailed to the
> list.
>
> Whilst the warning is harmless (I think), it can obscure other errors,
> so I would like to fix it.
>
> It looks like removing the net-smtp Gem solves the issue.
> When tested in Docker, this does not appear to affect the ability to
> send emails, so I propose to make the change in Whimsy -- unless I
> hear otherwise?

If you remove the net-smtp gem from the Gemfile, the require will fail
with ruby 3.1.2p20.

Perhaps add "unless RUBY_VERSION =~ /^2/" to that line in the Gemfile?

> Sebb

- Sam Ruby