<enebo>
I don't actually like that I have to do that but I have never gotten this to work without it (pretty much since starting 5.0 work)
lance|afk is now known as lanceball
lanceball is now known as lance|afk
lance|afk is now known as lanceball
<enebo>
holy crap...it is working not even without bundle exec!!!
<enebo>
s/not/now/
<enebo>
I broke both of your dev envs but fixed mine and ci...I wonder why we are different
<rdubya>
enebo: yeah it doesn't work for me either way, something changed recently that made it so I needed to start using bundle exec before your changes
<rdubya>
so I think that is a separate issue
<rdubya>
and may have something to do with whether you have a version of the activerecord gem already installed globally
<enebo>
rdubya: try this. unset RAILS and set AR_VERSION=v5.0.6
<enebo>
rdubya: then remove your .lock file and re-run bundler
<enebo>
I am wondering if the issue is that I made it only work in scenario where it git clones from bundler and does not work with a local checkout
akp has quit [Remote host closed the connection]
<rdubya>
enebo: that gets me into a weird spot, it's saying i don't have activerecord installed when I try to run the tests
<enebo>
rdubya: I see one obvious issue if RAILS was specified...I nuked ar_test_dir from working
<enebo>
but you just tried the other way and it broke so there are at least two things wrong
<enebo>
the bi-modal config option makes this a little more complicated than I think it needs to be as well
<enebo>
maybe we should just have RAILS be a version or a path and leave it to one thing
<enebo>
Or perahps makke RAILS only be a path and AR_VERSION only be a version and if both are set it is an error
<enebo>
sorry I partially expected something to break but ci and my local env works so I was hopeful at that point :)
<enebo>
rdubya: if you want to retry with your original RAILS env set you can try adding: ar_test_dir = File.join(ar_path, 'test')
<enebo>
into the if ENV['RAILS'] conditional
<enebo>
that at least will make the test/cases thing stop being an error (of original report)
<rdubya>
enebo: moving that fixed it
<enebo>
rdubya: well I think it should still be in original location as well
<enebo>
but now the test above the next conditional around is only testing ar_base and not the test dir
<enebo>
rdubya: ^ can you now change the unless to be this? :)
<enebo>
The unless assumes AR_VERSION is set to an v5.0.6 or something like that and bundler has ended using a git-backed gem
<enebo>
rdubya: another thing I wonder is if you unset RAILS as an env and set AR_VERSION and then remove .lock and run bundle install what you have in the new .lock file
<kares>
guys I just have used rake and was fine
<kares>
maybe my gemset was isolated and had the proper rake version
<enebo>
kares: yeah envs are tough :)
<kares>
(never actually used bundle exec - that would be slow, if I have to I just add -rbundler/setup)
<rdubya>
here's what I'm down to, any issues with putting it in this way?
<rdubya>
" try setting a local repository path e.g. export RAILS=`pwd`/../rails"
<rdubya>
raise "can not directly load Rails tests;" +
<rdubya>
unless File.exist? ar_test_dir
<rdubya>
ar_test_dir = File.join(ar_path, 'test')
<rdubya>
end
<kares>
+ it was now also working with MRI :)
<kares>
what we need to shell out `bundle info` ... najs :)
<kares>
so the RG API wasn't good?
<kares>
since you can do the same at runtime? // cc enebo
<enebo>
yeah I figure their may be an API for it but I did not know and this has not worked for like a month straight
<rdubya>
I just rearranged what enebo had in there
<kares>
yeah I noticed as I'm checking
<enebo>
I am not what I would call an expert in bundler
<enebo>
:)
<enebo>
kares: any chance we can simplify our build env a bit?
<enebo>
AR_VERSION and RAILS being able to be the same values makes this a bit more complicated than it could be
<kares>
well sure but I am not sure how much we could simplify
<kares>
it was the minimal thing
<enebo>
Let's just have one of those names supported
<kares>
we have to load foreign code ... thus the hacks
<enebo>
or are you saying something external to our code need RAILS and/or AR_VERSION set?
<kares>
well AR_VERSION was used previously for Gemfile - to be able to switch
<kares>
than RAILS got added with 5.0 changes to split the gem I guess
<kares>
nope it does not
<kares>
but I'd like to be able to switch AR_VERSION
<kares>
or do we really not need that?
<kares>
e.g. if testing against a Rails commit ...
<enebo>
When I originally started 5.0 env changes I just put the version of AR_VERSION we were using directly in the gemspec assuming we support only one version of AR
<kares>
we need both since CI does not have a checked out rails copy
<kares>
which I think itsbest - since it is actually simpler
<enebo>
which means tweaking config when new point release comes out but we basically do that already in .travis.yml and in our own ENV
<enebo>
I was just thinking you update gemspec and bundle install
<enebo>
It seems the less common path and it does not require remembering you need to set this variable
<enebo>
(which was why I asked you how I run tests 2 days ago)
<enebo>
I forgot somehow
<enebo>
I probably am taking us a bit off focus here. I guess we can think about it but I do not see a need for AR_VERSION unless we can somehow make it optional so you can do testing against a variant branch version
<kares>
but you do update gemspec with newer versionand bundle install
<kares>
by default it does work that way ... unless you set AR_VERSION (which is optional)
<kares>
or did I miss smt?
<enebo>
I have no idea I have hard time understanding the gem spec
<kares>
which line, the whole piece
<kares>
?
<enebo>
let me check
<kares>
the gemspec has a RELEASE hack
<kares>
but that is smt different
<kares>
which might confuse you
<enebo>
oh sorry I Gemfile not gemspec :)
<kares>
but otherwise plain old ruby gemspec :)
<enebo>
I find that conditional logic at the top confusing and I mean Gemfile for all of that (sorry that was confusing)
<kares>
okay so when AR_VERSION isn;t set
<kares>
you get
<kares>
gemspec name: 'activerecord-jdbc-adapter'
<kares>
which means use version of AR from gemspec
<kares>
yeah that logic is to somehow support branch/commit/tag from Rails
<kares>
we can simplify but we need tag at least + commit
<enebo>
kares: so originally I just had a single version number in the Gemfile (well it is possible it was .gemspec but I don't recall). If I wanted to test against another version I would change that single value.
<kares>
yes
<enebo>
kares: I can believe it is inadequate but I would like to know why so better understand this
<enebo>
as it stands if we change point release we change n lines in .travis.yml
<kares>
yeah that part is not ideal
<enebo>
Or locally we assume we have I guess latest AR installed
<kares>
but than we might need to lock down to a certain version at CI
<enebo>
so I think in general we want to lock to latest point until next point of AR is released then update to that new point but in general the golden path workflow is pretty much always a static number
<kares>
we could reduce that to 1 line in CI easily :)
<kares>
by having AR_VERSION="v5.0.6" globally
<kares>
but you still need to change manually onCI
<enebo>
For testing a branch or tag then perhaps a single value in Gemfile/gemspec is inadequate but I am trying to understand this part of it
<kares>
which I believeis good
<kares>
you do not want CI to automatically pull latest
<enebo>
So on 50-stable if I have no AR_VERSION set and no RAILS set what version is installed?
<kares>
actually it pbly does with non rails test atm
<kares>
latest 5.0.x
<kares>
that is the same with CI expect for Rails test since only they have AR_VERSION specified atm
<kares>
but than you need to account for Bundler -> if it installed a 5.0.x previously it will use that
<enebo>
aha ok gem.add_dependency 'activerecord', '~> 5.0.0'
<kares>
(you won't get latest automatically unless you `bundle install/update` explicitly)
<enebo>
so basically AR_VERSION allows us to be more specific than gemspec which is just latest
<kares>
yep
<enebo>
and then RAILS is added to allow local path
<enebo>
to rails repo
<kares>
yy
<enebo>
ok
<kares>
rdubya: how confusing are these for you (to me it seems 'standard' ruby gemspec setup by default but maybe I am opinionated here) ?
<kares>
enebo: so I'll look into some tweaks of getting it working locally for us
<kares>
hopefully I won't get you into trouble :)
<enebo>
kares: heh thanks for the explanation. I might take a stab at explaining some more of these details. I think seeing lines like version = ( ENV['AR_VERSION'] || ENV['RAILS'] ) is mostly what is confusing
<rdubya>
kares: I guess from my side I don't see the need for both vars since it looks like they are doing the same thing (from what I can tell) but I don't know where else they get referenced
<rdubya>
I think the system is good though
<enebo>
kares: I did figure there must be some mechanism for getting info path from bundler too but I wanted to see ci run and I didn't know
<kares>
that part is pbly fine
<enebo>
rdubya: I think it is from lines like above
<kares>
its wird its not booting
<kares>
* weird
<kares>
I mean for us locally
<enebo>
If would say RAILS should only be path and AR_VERSION should only be considered a version/tag but also that is RAILS is set AR_VERSION is ignored
<kares>
enebo: btw if you remove || ENV['RAILS'] from Gemfile
<enebo>
and however that logic is laid out we write that up in text instructions AND the code is a little more linearly
<kares>
than you bundle exec for rails's rake would stop working
<kares>
so its ugly but needed
<kares>
bare rake should/could still work however
<enebo>
yeah I am not trying to eliminate RAILS just change it so it just works for a local path
<enebo>
your logic makes it look like these two are for the exact same thing
<enebo>
which I think has confused us both
<enebo>
kares: I can change this code a tiny bit so you can see what I am thinking
<enebo>
kares: based on our discussion it might restrict how the envs work a tiny bit but probably make their definitions from anyone reading the code clearer
akp has joined #jruby
<kares>
well I do not mind - the problem is booting rails is tricky and I feel there will always be compromises if you simplify :)
<kares>
but I'mopen to changes as long as it works locally for me
<enebo>
well I am just trying to make RAILS and AR_VERSION not be the exact same behavior
<enebo>
and I am not totally sure whether they are at this point
<kares>
its not its mostly due convenience
<kares>
you would do export AR_VERSION=../rails
<kares>
that feels confusing right?
<kares>
btw. that is smt that was in historically
<kares>
I did not invent it just kept it as it was
<enebo>
well when you see two ENVs OR'd nearly every single person will wonder why there are two ENVs
<kares>
while if its named RAILS its more clear what it does
<kares>
but it isn't necessary
<kares>
you could just use AR_VERSION
<enebo>
I actually think both are ok so long as RAILS is only for specifying a path and it takes precedence and AR_VERSION only works with version strings
<enebo>
neither is just gemspec
<kares>
ah okay
<enebo>
I think that is explainable in three lines in a doc too
<enebo>
but you will never get asked again why we have 2 envs
<kares>
makes sene
<kares>
*sense
<enebo>
ok I will mock something up but not commit since you are looking into my recent breakage
<kares>
although I still think you might broke your bundle exec but we'll see:)
<kares>
well I'll be leaving in 0.5 hour and want be here till tomorrow so it might be on hold
<enebo>
kares: I can also take a crack if I can get which command-lines should work although I feel like something in my env is making this hard to tell
<enebo>
I definitely saw one mistake in working with rdubya in trying stuff
akp has quit [Remote host closed the connection]
<kares>
okay so it just a matter or not setting up ar_test_dir
<kares>
for both ways of resolving ar_path
<kares>
I'll commit
<kares>
done ... enebo if it works for you, which I am pretty sure it does we should be all fine now :)
<enebo>
kares: ah cool I will try
akp has joined #jruby
akp_ has joined #jruby
akp has quit [Read error: Connection reset by peer]
<enebo>
kares: AR_VERSION with nuking .lock and rerunning bundler works
<enebo>
trying each of the three variants
<enebo>
no envs next (I will nuke .lock and bundle install for each scenario)
<enebo>
with no envs set it is broken
<enebo>
weirdly with RAILS env set to `pwd`/../rails is blows up with: NameError: uninitialized constant ActiveRecord::ConnectionAdapters::PostgreSQL::OID::Rails51Point
<enebo>
So I am ok with AR_VERSION atm with latest changes which also should work with ci
<enebo>
kares: ^ so maybe still some work but we probably all work with AR_VERSION
<enebo>
rdubya: ^
<rdubya>
i believe that error happens when running the 50-stable branch against rails 5.1
<enebo>
rdubya: you were correct! I will retry RAILS now
<enebo>
kares: rdubya: AR_VERSION or RAILS seem to work for me locally not setting either does not
akp_ has quit [Remote host closed the connection]
akp has joined #jruby
akp has quit [Remote host closed the connection]
akp has joined #jruby
akp has quit [Remote host closed the connection]
xardion has quit [Remote host closed the connection]