search

MSP-Greg / ruby_on_windows

Empty repo for Ruby Windows issues
https://msp-greg.github.io/
MIT License
0 stars 0 forks source link

Appveyor - new builds... #5

Open MSP-Greg opened 7 years ago

MSP-Greg commented 7 years ago

@larskanis

First of all, congratulations. When I got the email, I really hoped that you were also nominated. I wondered that, while you were working on RI2, I might have been more visible to the core team because of all my 'communication' about trunk tests. I'm glad they're aware of your contributions.

There was some kind of Ruby event this weekend, and there were a lot of commits. Early on, the AV mswin build stopped working (and is still broken), so anytime I was near my computer, I'd start a new build. At times, it was running continuously. The issues I brought up were addressed, and it's still running with (basically) no failures/errors. Some OpenSSL issues, but that's probably due to the fact that Travis ruby-head may not be using 1.1.0, night even be using 1.0.1...

Anyway, re Appveyor. I wish you'd reconsider the idea of a fresh install.

  1. I've been overwriting my daily ruby trunk for months, and I've don't ever recall seeing the default gem list get garbled when running gem list. I do gem cleanup from time to time, but we're talking weeks, as opposed to new builds are daily or better...

  2. Some of the 'duplicate gems' are default gems, and having been in the Bundler and RubyGems repos, this stuff is still pretty new. FYI, Bundler has never tested with AV, but RubyGems is and is also using my trunk build. But, as I'm sure you know, Bundler is used a lot for CI test setup.

  3. I've been working more with Travis (although much less than AV), and don't recall any of their versions having the gem clutter.

  4. Taking OpenSSL or JSON default gems as an example. Both have two gemspec files, so gem list is showing them. But, I think only the most recent is installed. Hence, if someone has bundler set to a particular version (common, I've seen amazing things using trunk) which matches the older gemspec, things might get amiss...

  5. I think the AV guys are probably spread a little thin...

FYI, I've got a script that can probably do everything AV needs, output is here. Updates RubyGems and adds Bundler. If you decide a fresh build maybe the way to go, I can pass it along to the AV guys.

Thanks again, Greg

larskanis commented 7 years ago

Congratulations to you as well! Will you be there in Matsue at the conference?

Regarding appveyor install: I don't have a strong opinion to this. Both versions of OpenSSL and json should be working, although only the newer one is used unless the older is explicitly specified. If not, it's a bug in RubyInstaller2 or rubygems. Did you encounter anything not working?

MSP-Greg commented 7 years ago

Will you be there in Matsue at the conference?

No. Will you? Hopefully, someday I'll attend, as its always nice to meet people face to face...

Both versions of OpenSSL and json should be working.

I'm missing this.

First of all, I'm not familiar with the 'Inno Setup' installer. Let's assume that AV is installing Ruby from the *.7z files, so an existing 2.4.1 install is in place, and 2.4.2 is extracted into it.

For bundled gems, there are version specific folders that they install into, along with a few version specific files (.gem, .gemspec). For default gems, there are no version specific locations, and the only file that is version specific is the *.gemspec file.

Hence, it seems to me that, for an 'in-place' upgrade, there will be only one set of files for OpenSSL/JSON. But, there may be more than one gemspec. Which may or may not confuse RubyGems / Bundler...

What am I missing?

larskanis commented 7 years ago

Will you?

I don't think so.

Both versions of OpenSSL and json should be working.

For default gems, there are no version specific locations

OK, now I got it! I thought about bundled gems first.

Current RubyInstaller2.exe makes an upgrade by simply overwriting all installed files and adding new files. This was how RubyInstaller1 worked and obviously works for most people. It's known to leave some artifacts in the start menu (see #78). It obviously also leaves the old gemspecs for default gems.

I already planned to switch to a smarter upgrade procedure in RubyInstaller2.exe. It will deinstall the previous package before installing the new one. The deinstallation will not touch any bundled gems nor gems installed per gem install.

MSP-Greg commented 7 years ago

OK, now I got it!

If, for every time I didn't get it, I had a dollar...

I already planned to switch to a smarter upgrade procedure in RubyInstaller2.exe. It will deinstall the previous package before installing the new one.

A good idea, but potentially unstable... But, a very good idea. Since I use trunk and don't package with the installer, I don't normally trip over that kind of issue. I can test against an RI2 build, so let me know when you move forward...

EDIT: I assume you'll leave installed gems? That's the only reason I do 'in-place' updates'...

Back to Appveyor. Maybe you could let them know there are issues, and we're working on it?

I've got the start of a script that should work for them (AV), it downloads the two builds (32 & 64) from GitHub, puts them in temp folders, adds bundler, updates rubygems, then renames old, renames temp to old, then deletes old (new location) & downloads, etc.

Main thing holding me up right now is files added in the bin folder by gems. I've got code working in my trunk (ruby-loco) system that works, but, under the assumption that they're called from the same folder that PATH points to. It also affects the 'reproducible build' issue (I consider a proper 'reproducible build' to contain no hard coded paths.)

AYK, some of the files will be installed with a hard coded path included with ruby.exe. My current code replaces that with just ruby.exe. It should really replace it with %~dp0ruby.exe. But I'm having some issues with works local and in AV ruby-loco, but not in my current script on AV. When I get that sorted out...

Said another way, the issue is that my preference is that, for two ruby installs A & B, with A_bin_path and B_bin_path:

  1. no paths should be hard coded in any files in the A or B bin folders

  2. If ENV['PATH'] contains A_bin_path, and from a cmd prompt one does

    B_bin_path\bundle env

    One should see the info from the B install.

I hope this makes sense, and if you have any thoughts on it. I'll file an issue in RubyGems about replacing the hard coded paths with %~dp0 on windows platforms... Thanks.