<locks>
since Bundler came along I tend not to use'em
<solnic>
I don't use gemsets
<solnic>
for deps-heavy projects I use VMs
<solnic>
to isolate from my main OS
<solnic>
for the rest - I just don't care
<soveran>
locks: the idea is to avoid using bundler
f-3r has quit [Ping timeout: 246 seconds]
<locks>
soveran: why?
<pote__>
solnic it moves dependencies to a directory within the project, which is super straightforward. I use VMs when there are dependencies on a project that I can't isolate
<soveran>
locks: are you familiar with npm?
<pote__>
but a lot of cases don't need them, so I prefer to use something simpler
<locks>
soveran: I know of it, not the internals
<solnic>
oh I see
<solnic>
there's another project that uses this approach
<solnic>
it's called deps or something like that
<soveran>
solnic: gs + dep
<solnic>
oh, right!
<soveran>
gst is inspired on gs actually
<soveran>
locks: the idea of npm is to tackle the problem of dependencies, same as what you solve with rubygems + bundler
<soveran>
but they do something very smart, which is to install the dependencies per project, instead of using a global space
<locks>
right
<pote__>
Yeap, gst is inspired by gs, just implemented in a slightly different manner but the concept is almost the same, I used gs before gst. :)
<pote__>
(And still use dep)
<soveran>
what bundler solves is in part a self inflicted problem we have, which is to install all the games in the same global space
<solnic>
it's the same in python and virtual env
<soveran>
installing all the dependencies in the global space is efficient in terms of storage
<soveran>
(because you have each gem only once)
<soveran>
but it's inefficient in terms of dependency resolution
<locks>
doesn't npm cash it somewhere globally?
<locks>
like leiningen
<soveran>
you can force npm to install globally, but the default is local, per-project
<soveran>
most people go with the default
<soveran>
because space is cheaper than cpu
<soveran>
and also because solving the problem that way (trading space for time and complexity), results in simpler tools
<locks>
well.
<soveran>
rubygems: 16k loc, bundler: 10k loc
<soveran>
you need more effort to solve the computational problem
<locks>
space is also cheaper than bandwidth
<soveran>
so what you get with gs + deps is that tradeoff: all the dependencies are local to the project, but you avoid dependency resolution problems
<soveran>
and if you approach the problem that way, you can solve it with less than 50 lines of code
<soveran>
it could even be a oneliner
<soveran>
the way it solves it is by setting different values for GEM_HOME and GEM_PATH
<soveran>
in order to tell rubygems to install the dependencies to a local directory
matiasow has joined #microrb
<soveran>
for your project, the local gems is all there is
<soveran>
so you don't get conflicting dependencies
<soveran>
as solnic mentioned, some other programming languages have similar tools
<soveran>
virtual env for python, npm for node, gpm + gvp for golang, etc.
<pote__>
I'm glad this channel is picking up some momentum and we have these kinds of discussions though :)
<pote__>
frodsan: btw, I haven't even looked at the way lua rocks are installed, but if you poke around that please let me know, I'm interested.
<solnic>
pote__: yeah I'm loving it :)
<solnic>
pote__: I'll be speaking about microrb on at least 2 confs this year btw
<pote__>
Oh, nice.
<skade>
re: npm: npm leads to a very weird dance of having some things installed globally and some not
<solnic>
one is wroc_love.rb and the other is...I can't tell :D
<pote__>
I'm thinking of a talk based on simplicity vs complexity, my intent is to mention #microrb too there, if it gets accepted somewhere
<skade>
e.g. it is not unusual to install grunt globally but also locally through
<solnic>
yeah I've used npm few times and it was hell
sborrazas has joined #microrb
<solnic>
very very slow and left me in a weird state at least 2 times
<solnic>
me as in my environment ;)
<solnic>
pote__: that's really cool!
<skade>
I love how programmers speak of their programs in first person...
<skade>
"If I crash here, while the other thread is running..."
<skade>
(quote from wroc_love.rb 2013)
<pote__>
hehe
<solnic>
pote__: my talk is a bit meta but I plan to focus on small libs vs monolithic, ma "hatred" towards monkey-patching and AS and of course microrb
<skade>
it gets worse if bower, etc are also involved... the main directory of many javascript libraries has at least 3 files expressing dependencies
<skade>
soooo... wrong side of micro
<solnic>
that's not nice
<pote__>
solnic: we'll see, I still have to write it, I think I have a few good talking points, but as always it's mostly going to be "there are tradeoffs to everything and I don't think we stop to think about the tradeoffs of complexity often enough"
<locks>
bower and npm specify different dependencies
<locks>
that makes sense
<locks>
for example
<solnic>
pote__: yeah I'm thinking about something like that too
mostr has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
soveran has joined #microrb
soveran_ has joined #microrb
soveran has quit [Disconnected by services]
soveran_ is now known as soveran
soveran has quit [Changing host]
soveran has joined #microrb
matiasow has quit [Remote host closed the connection]
soveran has quit [Ping timeout: 245 seconds]
soveran has joined #microrb
frodsan has quit [Remote host closed the connection]
frodsan has joined #microrb
f-3r has joined #microrb
patriciomacadden has quit [Remote host closed the connection]
patricio_ has joined #microrb
soveran_ has joined #microrb
soveran has quit [Ping timeout: 260 seconds]
grilix has joined #microrb
f-3r has quit [Ping timeout: 245 seconds]
soveran_ is now known as soveran
soveran has quit [Changing host]
soveran has joined #microrb
<elskwid>
soveran: I missed the first part of this convo but catching the end I'd say, what about projects where bundler is already in use? I am not going to convince everyone to come along.
<elskwid>
I actually use bundler like this now: bundle install --binstubs .bundle/bin --path .bundle which gives me npm-like locality
<elskwid>
and, in some cases, I add .bundle/bin to my $PATH so I don't need `bundle exec` everywhere.
<elskwid>
(I know it's a security concern ...)
<soveran>
elskwid: if bundler is already in use and people working on it are hard to convince, you are stuck
<soveran>
it's a de facto standard, so people have to really buy into the idea of using something different
<soveran>
in my experience, most people just don't mind using bundler
<soveran>
there are some that are just not sensitive to lines of code or complexity, or even time
<elskwid>
soveran: it's a ball of mud.
<soveran>
rubygems: 16k loc, bundler: 10k loc, and you haven't even started your project
<soveran>
in a way, you are already dealing with 26k lines of code
<elskwid>
soveran: totally agree.
<solnic>
soveran: that's an interesting way of looking at things
<soveran>
I say "in a way" because you don't feel they are part of your project
<solnic>
really really cool
<soveran>
but if you step into a bug in one of those tools, you will quickly realize they were part of your project all along
<elskwid>
The same people that won't think twice about using those tools will complain about project deps.
<elskwid>
soveran: yes, a great way to look at it.
<elskwid>
a keen insight
<soveran>
let's say you create a new rails project, and you test it with rspec
<soveran>
btw, I'm not trashing those libraries
<soveran>
just examples
<soveran>
rails, let's say it's 50k lines of code
<soveran>
(it's a bit more)
<soveran>
rspec, 14k loc
<soveran>
that's a bit over 90 loc
<soveran>
and you haven't even started
<soveran>
ok, so if that code is perfect, there's nothing to worry about
<elskwid>
lol
<elskwid>
"There's nothing to worry about."
<soveran>
but the bug per line of code ratio is very similar across projects
<elskwid>
I'm thinking you need to add that to your bio somewhere.
<soveran>
if we consider open issues, bug reports, etc, there's a bug every 30 lines of code or so
<soveran>
if you start with 90k loc, your chances of bumping into a bug are very high
<soveran>
even if there are many eyeballs, etc.
<solnic>
soveran: 242677 loc
<solnic>
I just counted
<solnic>
but that includes tests
<solnic>
95403 loc w/o tests
skade has quit [Quit: Computer has gone to sleep.]
<soveran>
95k lines of expressive, high level ruby code
<solnic>
AR is 31805 loc
<solnic>
1/3 of whole rails
<solnic>
:D
<soveran>
wild
<elskwid>
egads
<soveran>
last year a guy presented at RubyConf Uruguay, and it was about debugging Rails
<soveran>
and how he managed to use some tool to debug something with url_for
<soveran>
turns out there were like 14 definitions of url_for
<soveran>
so part of the process was checking which one had the bug
<soveran>
anyway, that sounds like torture to me
<soveran>
going back to vanilla bundler
<soveran>
you have one rails project from last year, that's 40 gems
<soveran>
you start another rails project now, another 40 gems
<soveran>
80 gems in the same global space, of course you need bundler
<frodsan>
that's true. I worked on Rails documentation and it was painful to check how many options/results a method can handle (especially AR).