nil78 has quit [Read error: Connection reset by peer]
cahoots has joined #ruby
<cahoots>
hi, i've pushed a couple new versions of my gem, 0.1.2 and 0.1.3, in the past day or two. however, rubydoc.info only shows 0.1.1. any ideas what the issue is? and do you guys prefer rubydoc.info for hosting your docs, or somewhere else?
nil78 has joined #ruby
<cahoots>
oh nm, i forgot to publish 0.1.2 and 0.1.3 is too new
CRISPR has joined #ruby
graywolf has quit [Quit: WeeChat 4.5.2]
nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #ruby
jasfloss has quit [Ping timeout: 252 seconds]
nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #ruby
eddof13 has joined #ruby
gr33n7007h has quit [Ping timeout: 244 seconds]
gr33n7007h has joined #ruby
jasfloss has joined #ruby
cahoots has quit [Ping timeout: 260 seconds]
gemmaro_ has quit [Ping timeout: 252 seconds]
gemmaro has joined #ruby
<dorian>
hey question: say i was working on a rack app and wanted to fake up eg REMOTE_USER
<dorian>
it seems like i can't just pass environment variables off the shell, is there a middleware or something that does that?
cahoots has joined #ruby
CRISPR has quit [Ping timeout: 244 seconds]
cahoots has quit [Ping timeout: 245 seconds]
<o0x1eef>
dorian: Do you mean you want to inject something into the 'env' Hash that is passed through a Rack request ? Then yeah, a middleware would do it. I'm not sure I understand your question though
eddof13 has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<dorian>
so i'm trying to develop a rack app, and i want to be able to spin it up from the command line with a fake REMOTE_USER set
<dorian>
eg plack for perl has a ForceEnv middleware and you would do something like `plackup -e 'enable ForceEnv => REMOTE_USER => q{lol@whatever}' myapp
<dorian>
which is handy
<dorian>
but i'm not seeing anything like that for rack in the index
<o0x1eef>
I have never heard of REMOTE_USER :/ But it sounds like you want a middleware that will inject some state into the env hash. You could do this based on the presence of ENV['FAKE_REMOTE_USER'] in config.ru
denvermullets has joined #ruby
<dorian>
REMOTE_USER is just the cgi environment variable that holds a username from some upstream authentication handler
<o0x1eef>
I don't know of any middleware like ForceEnv so you would probably have to write it
denvermullets has quit [Ping timeout: 252 seconds]
<dorian>
eh yeah i'm sure i can hack it in; just didn't want to have to lol
konsolebox has joined #ruby
cahoots has joined #ruby
<nakilon>
should method be defined as a class method if it does not use instance attributes? it feels like it should be there, but if I make it private to prohibit invoking from elsewhere, then from the instance I have to use '.send' too
cahoots has quit [Ping timeout: 244 seconds]
<nakilon>
or should I make it an instance method just to avoid the 'self.class.send' ? should instance have methods (even private) if they don't access attributes?
<nakilon>
the crud method isn't needed anywhere outside so I made it private, but while being a class method, it becomes inaccessible for the instance too, right?
<nakilon>
that's why the "send" thing in the line 23, and I don't understand if it's ok to have it like thisor not
<o0x1eef>
Probably I'd make the "crud" method a private instance method, pass 'field', and perform look ups with 'field'.
<o0x1eef>
Sorry field_name *
<nakilon>
and I don't like the document_class either but it's probably another problem
<nakilon>
*different
<o0x1eef>
That's also a bit strange, agreed
<o0x1eef>
'self.crud' could be instance state.. @crud ||= { .. }, then @crud[field_name].
<nakilon>
the Field obtains the schema location from the passed class, for methods needs
<o0x1eef>
It could also potentially be a constant. Then you should be able to access at the class and instance level. document_class::CRUD[field_name].
<nakilon>
oh, the example misses it; crud is a method, because on lookup failure it should print a nice error message, and it was invoked from several places in document class
<o0x1eef>
Given all that context, it might be simplest to just not make it a private method.
<o0x1eef>
In your example though, where there is .send, it's not neccessary
<o0x1eef>
It's only neccessary if you do document_class.crud
<nakilon>
hmmm
cahoots has joined #ruby
<nakilon>
yeah the send does not seem to be needed here, but the crud is being invoked from document instance method; because when I initialize the document I pass the values using the same user ui keys, like tab and field name
cahoots has quit [Ping timeout: 244 seconds]
<nakilon>
and so the doc attributes are stored in the instance as a Hash that is being looked up with that same method crud
<o0x1eef>
And a field creates the document instance ?
<o0x1eef>
Probably the most simple and straight forward solution is to avoid making the method private
denvermullets has joined #ruby
<o0x1eef>
Or, when you create the document instance, do the same as the field_new: Field.new self, crud(field_name) but like DocumentTypeA.new crud(field_name). So you would add a constructor at the class level in a similar way: DocumentTypeA.new_document(...)
denvermullets has quit [Ping timeout: 268 seconds]
cahoots has joined #ruby
cahoots has quit [Ping timeout: 268 seconds]
<nakilon>
no, both doc and field instances are created by library user
nil78 has quit [Read error: Connection reset by peer]
denvermullets has quit [Ping timeout: 246 seconds]
hansolo has joined #ruby
denvermullets has joined #ruby
denvermullets has quit [Ping timeout: 248 seconds]
grenierm has joined #ruby
nil78 has quit [Read error: Connection reset by peer]
<henk>
yet again I wonder if my question was bad, lacking information, etc. or just no one knows anything about this topic. any feedback welcome!
nil78 has joined #ruby
denvermullets has joined #ruby
denvermullets has quit [Ping timeout: 252 seconds]
sunyour has quit [Quit: sunyour]
sunyour has joined #ruby
konsolebox has quit [Remote host closed the connection]
denvermullets has joined #ruby
denvermullets has quit [Ping timeout: 252 seconds]
cahoots has joined #ruby
wbooze has joined #ruby
cahoots has quit [Ping timeout: 260 seconds]
wbooze has quit [Ping timeout: 268 seconds]
wbooze has joined #ruby
denvermullets has joined #ruby
user71 has joined #ruby
mange has joined #ruby
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ruby
sarna has quit [Ping timeout: 260 seconds]
rvalue- has joined #ruby
rvalue has quit [Ping timeout: 268 seconds]
denvermullets has quit [Ping timeout: 272 seconds]
rvalue- is now known as rvalue
TomyWork has joined #ruby
cappy has joined #ruby
mange has quit [Read error: Connection reset by peer]
yosafbridge has quit [Quit: Leaving]
yosafbridge has joined #ruby
grenierm has quit [Quit: Client closed]
mange has joined #ruby
denvermullets has joined #ruby
nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #ruby
cahoots has joined #ruby
cahoots has quit [Ping timeout: 248 seconds]
mange has quit [Quit: Zzz...]
denvermullets has quit [Ping timeout: 272 seconds]
user71 has quit [Quit: Leaving]
<o0x1eef>
henk: This doesn't answer your question directly but few thoughts. When a process receives SIGINT, Interrupt will be raised. Any other exception will raise SignalException (eg SIGUSR1). Then, with this knowledge, I think the code becomes easier to reason about like so: https://gist.github.com/0x1eef/ad06b212e9803a5cb70058f8f57e0eef
nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #ruby
<o0x1eef>
Also keep in mind that code should be on the main thread
nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #ruby
denvermullets has joined #ruby
denvermullets has quit [Remote host closed the connection]
nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #ruby
Guest11 has joined #ruby
Guest11 has quit [Ping timeout: 240 seconds]
nil78 has quit [Read error: Connection reset by peer]
Guest35 has joined #ruby
nil78 has joined #ruby
Guest35 has quit [Quit: Client closed]
<nakilon>
maybe I should not have the Field class at all but have DocumentTypeA#field_generate(*field_name) and DocumentTypeA#field_format(value, *field_name)
<nakilon>
because it's not a problem to derive/obtain/access schema on every call, and besides of that I don't store anything, the Field is essentially is not a storage
<nakilon>
so I don't need an instance
Guest35 has joined #ruby
cahoots has joined #ruby
<o0x1eef>
Makes sense (I'm missing the bigger picture tho)
donofrio_ has joined #ruby
cahoots has quit [Ping timeout: 244 seconds]
Guest35 has quit [Quit: Client closed]
cappy has quit [Quit: Leaving]
fantazo has quit [Quit: Lost terminal]
<henk>
o0x1eef: alright, thank you
user71 has joined #ruby
reset has joined #ruby
donofrio_ has quit [Quit: Leaving]
cahoots has joined #ruby
blacknova has joined #ruby
cahoots has quit [Ping timeout: 252 seconds]
sarna has joined #ruby
cahoots has joined #ruby
cahoots has quit [Ping timeout: 268 seconds]
ih8u2 has joined #ruby
ih8u has quit [Ping timeout: 252 seconds]
ih8u2 is now known as ih8u
factor has joined #ruby
<henk>
what’s state of the art tracing in ruby? I get errors from a socket function and there are quite a few places that might call it, I want to find out which one it really is … I found TracePoint but in a post from 2017, so no idea whether that’s the way to go.
<CalimeroTeknik>
it's weird, some work and some don't
<adam12>
CalimeroTeknik: If you're not calling `bundle exec` or` require "bundler/setup"` inside your IRB instance, then anything installed from `git` wont' be available.
<CalimeroTeknik>
ah! how can I make it available?
<adam12>
CalimeroTeknik: Make sure you're in a Bundler environment.
<adam12>
Git-based dependencies are installed and managed elsewhere, which bundler just adds to `$LOAD_PATH`.
<CalimeroTeknik>
I don't want to ever ever ever require "bundler/setup" again
<CalimeroTeknik>
maybe there is another tool?
<adam12>
CalimeroTeknik: Drop the git dependencies. Fork gem. Build gem. `gem install <gem name>.gem`.
<CalimeroTeknik>
to install with gem install, for example, the Gemfile contents
<adam12>
There's `gem install -g Gemfile` but I don't recall it supporting git deps.
<CalimeroTeknik>
all by hand? fair enough I guess
cahoots has joined #ruby
__jmcantrell__ has quit [Ping timeout: 252 seconds]
cahoots has quit [Ping timeout: 244 seconds]
__jmcantrell__ has joined #ruby
jmcantrell has quit [Killed (silver.libera.chat (Nickname regained by services))]
__jmcantrell__ is now known as jmcantrell
jmcantrell_ has joined #ruby
<CalimeroTeknik>
ah! gem intall -g Gemfile installs stuff that is already installed as system gems
<CalimeroTeknik>
and it did correctly install the git deps, but they're installed the same as bundler / by bundler
<CalimeroTeknik>
they go to ~/.local/share/gem/ruby/3.1.0/bundler/gems/ instead of ~/.local/share/gem/ruby/3.1.0/gems/ but setting GEM_PATH=$HOME/.local/share/gem/ruby/3.1.0/bundler doesn't make them loadable
hwpplayer1 has quit [Remote host closed the connection]
hwpplayer1 has joined #ruby
cahoots has joined #ruby
cahoots has quit [Ping timeout: 244 seconds]
<CalimeroTeknik>
can `bundle exec` be brought to not "disallow loading additional gems not in the bundle", which I quote from https://bundler.io/man/bundle-exec.1.html?
<adam12>
CalimeroTeknik: I'm not familiar of a technique to do that.
<CalimeroTeknik>
then I'm after a way to load gems installed from git by bundler
<CalimeroTeknik>
from bare ruby
<o0x1eef>
AFAIK gem install -g supports git gems
<CalimeroTeknik>
yeah, but installs them with bundler, making it the same problem again
<CalimeroTeknik>
how can these be loaded in bare ruby?
fantazo has joined #ruby
<CalimeroTeknik>
at least it installs them in the same path as when bundler does it
<CalimeroTeknik>
how do you mean this to allow me to load git gems installed from a Gemfile, whether by gem install -g, or by bundle install?
<o0x1eef>
This allows you to install gems via git (gem specific_install /path/to/git/repo)
<CalimeroTeknik>
or whatever other method; if it's down to making me install one gem at a time manually, I can already clone, gem build and gem install
<o0x1eef>
I don't really understand what problem you're trying to solve
<CalimeroTeknik>
I was hoping to just be able to load what bundle installs from bare ruby (without bundle exec or require 'bundle/setup')
<CalimeroTeknik>
because otherwise, I can't load system gems at the same time, which is why I avoid bundle exec or require 'bundle/setup' like the plague
<o0x1eef>
By default bundler should install gems as system gems, but git gems might be the exception. I don't know any good work around for that
<CalimeroTeknik>
yeah, they're an exception! they install to a 'bundler' subdir, and I can't seem to get them to load by meddling with GEM_PATH
<CalimeroTeknik>
I don't know how GEM_PATH works, which might not help and have failed my attempts on something that flew over my head
<o0x1eef>
I don't know any good fix for that sorry
<CalimeroTeknik>
out of curiosity, why doesn't it work when I set GEM_PATH to a directory where there is for example, a 'eb-98ae28' directory, to `require 'eb'`? what is `require` looking for?
<CalimeroTeknik>
this should be ultra-basic, perhaps strace will answer me
<o0x1eef>
You misunderstood me :) $LOAD_PATH is a global variable within Ruby. For a shell variable I think you're looking for RUBYLIB.
<o0x1eef>
And it should also contain the lib directory of whatever gems you want to require
cahoots has quit [Ping timeout: 268 seconds]
<o0x1eef>
I think you're making life harder than it needs to be with this approach though
<CalimeroTeknik>
phew! a basic success! RUBYLIB=$HOME/.gem/ruby/3.1.0/bundler/gems/rubyeb19-b434e8dfadd0/lib/ ruby <<< "require 'eb'"
<CalimeroTeknik>
but there's nothing similar that would allow for this? MAGICVAR=$HOME/.gem/ruby/3.1.0/bundler/gems/ ruby <<< "require 'eb'"
<CalimeroTeknik>
or perhaps MAGICVAR=$HOME/.gem/ruby/3.1.0/bundler, where MAGICVAR suspiciously looks like GEM_PATH
<o0x1eef>
You could try move rubyeb19-b434e8dfadd0 to a directory named eb, and where other system gems reside (like ~/.local/share/gem/ruby/3.2/gems/) but basically I don't see any magic fix here. The easiest solution would be to try work with bundler.
<CalimeroTeknik>
it's not possible: there's no option to make it allow loading gems outside of the bundle
<CalimeroTeknik>
this is by design
<o0x1eef>
Why can't you declare all dependencies in the Gemfile?
<CalimeroTeknik>
I've tried that for years, and it always broke with system updates
<CalimeroTeknik>
I'm tired of it now, and I want to break free from bundler preventing the program from running, when it *would* run
<CalimeroTeknik>
until bundler becomes portage or apt and manages the entire OS, it's a failed concept
<o0x1eef>
Alright. So if you want to avoid bundler, then you'll have to rely on 'gem install', and installing git repositories from source. The specific_install gem might help. You're in a weird situation that's far from normal, you want to use bundler and not use it at the same time.
<CalimeroTeknik>
the thing is, 'gem install' installs git gems to a 'bundler' subdirectory!
<CalimeroTeknik>
it's a conspiracy ;)
<CalimeroTeknik>
and there seems to be no env var I can set to something to make those gems load
<CalimeroTeknik>
even if I don't use bundler, bundler will reappear from within gem install
<o0x1eef>
That's only with gem install -g
<o0x1eef>
You could have a gems.txt file and just install the gems with a shell script.
<o0x1eef>
for g in $(cat gems.txt); do gem install ${g}; done or sth like that
<adam12>
IMHO, anything installed through portage/apt/whatever is going to be way more brittle.
<adam12>
The reason Bundler works like this is because of the pain experienced before Bundler existed.
<CalimeroTeknik>
no, it's not brittle, because system package managers, in particular portage, will rebuild ELF objects as needed, to prevent "cannot load shared libraries" errors and such
<CalimeroTeknik>
this is something that on the contrary, makes any native extension installed by bundler brittle
<adam12>
I see what you mean, but you're essentially just trading the stability of the C shared libraries for the Ruby libraries.
<CalimeroTeknik>
what could possibly happen with the Ruby libraries in terms of stability? it's granted that I'm guaranteeing that the versions I install are compatible with my project
<adam12>
CalimeroTeknik: How are you doing that tho?
<adam12>
You don't want to use bundler.
<adam12>
Are you using Kernel.gem?
<CalimeroTeknik>
adam12, portage atom specifications, basically flexible specification of version
<adam12>
Of a ruby gem? or of a C ext.
<adam12>
s/ext/lib
<adam12>
And then you're guaranteeing that only one version of that gem is installed?
<CalimeroTeknik>
I must confess that I'm unsure if I understand "trading the stability of the C shared libraries for the Ruby libraries."
cappy has quit [Quit: Leaving]
<CalimeroTeknik>
actually: any version works for me. to bundler: please stop freezing versions and preventing things to load
<CalimeroTeknik>
I like security updates, too
<CalimeroTeknik>
I'm not sure what stability I'm relinquishing
<CalimeroTeknik>
text files don't link to one another, as long as interface contracts aren't broken by careless developers
<CalimeroTeknik>
all is fine
<CalimeroTeknik>
and I know that's the problem Gemfile.lock solves with ice
<CalimeroTeknik>
but that's a problem I do not have, because I'm careful about what I install, and take upon myself any regression issues
<CalimeroTeknik>
they're more rare than the problems brought by version locking
hwpplayer1 has quit [Quit: I'll be back later]
jmcantrell has quit [Ping timeout: 260 seconds]
jmcantrell_ is now known as jmcantrell
<o0x1eef>
Do you want to install gems via portage as well?
<o0x1eef>
If that's the case then just package your dependencies that way, but your current approach is going to be like climbing mount everest.
<adam12>
CalimeroTeknik: Sorry, I don't have a ton of time to explain this. My time to help people is limited. Most Ruby applications contain the majority of their implementation in Ruby. The libraries that they link to are typically less at risk of churn when they play a much smaller role in the overall functionality of the Ruby application.
<adam12>
If you think you're good going the path you are, that's fine. I have no interest in arguing.
<CalimeroTeknik>
o0x1eef, the only problem I face is that bare ruby won't load gems installed from git from a Gemfile, really. I'm engineering a RUBYLIB-based solution
<CalimeroTeknik>
my only gripe is that the tools break on this specific exception
<o0x1eef>
Right. They're not designed according to your expectations. It sounds like you expect your system manager to manage everything, and that's ok, FreeBSD also packages gems, and in your case that might be better, but with this approach, it just sounds painful to work with, you'll waste a lot of time on it and probably end up with something that's subpar.
joako has quit [Quit: quit]
<CalimeroTeknik>
I feel that your answer is the YX problem (opposite of XY problem)! if ruby could `require` gems that were installed from custom git repos, all would be well.
<CalimeroTeknik>
this exception is baroque
<o0x1eef>
Here's what I would do if I was you. Grab the specific_install gem. Add gems.txt to your project. Add bin/setup and within bin/setup, add "for g in $(cat gems.txt); do gem specific_install ${g}; done". Then call it a day, otherwise, you can continue down this path and probably continue to be frustrated.
<CalimeroTeknik>
I'm removing the exception of unloadable git gems
<havenwood>
Just a note, `gem i -g` does support git.
<CalimeroTeknik>
havenwood, we have established that it installs to GEM_PATH/bundler/gems instead of GEM_PATH
<CalimeroTeknik>
and that trying to set GEM_PATH to itself/bundler/gems doesn't allow to load them
<CalimeroTeknik>
hence the script I just posted
<havenwood>
CalimeroTeknik: The default bundler path is the gem home.
<CalimeroTeknik>
not for git gems!
<CalimeroTeknik>
it's a baroque exception
<CalimeroTeknik>
and gem i -g installs to a bundler subdirectory, which is remarkably odd
<havenwood>
CalimeroTeknik: Well, you can set Bundler to do that, but it's not the default.
<CalimeroTeknik>
hold on, I'll try to see if I can make bundler install to the gem home without funny subdirectory business.
<CalimeroTeknik>
…for git gems specifically
<CalimeroTeknik>
nothing in ~/funny with GEM_HOME=~/funny bundle install
cahoots has joined #ruby
geewiz has quit [Remote host closed the connection]
<havenwood>
CalimeroTeknik: If you `bundle init` and add something like `gem "persist", github: "havenwood/persist"` then `gem i -g --no-lock` and `gem which persist` does it not *just work*?
<havenwood>
If not, check your `bundle config` for something funky.
<CalimeroTeknik>
ah, no! it wasn't. `gem "persist", github: "havenwood/persist"` does "just work", but `gem "eb", github: "k5bot/rubyeb19"` does not work
<CalimeroTeknik>
I mean it installs and all, but require 'eb' fails
<havenwood>
CalimeroTeknik: What does `gem which eb` show?
<CalimeroTeknik>
I even tested on a new user on the system, and it installs the two gems in different places
<CalimeroTeknik>
aha! /home/derpson/.local/share/gem/ruby/3.1.0/bundler/gems/ contains both eb-b434e8dfadd0/ and persist-76daa097968d/
<CalimeroTeknik>
but /home/derpson/.local/share/gem/ruby/3.1.0/gems/ contains just persist-1.0.0
cahoots has quit [Ping timeout: 248 seconds]
<CalimeroTeknik>
no idea why bundler invites itself here, if you see what I mean; I used `gem i -g --no-lock` only
<CalimeroTeknik>
`bundle config` outputs "Settings are listed in order of priority. The top value will be used."
<havenwood>
CalimeroTeknik: The eb gem does have a C extension.
<CalimeroTeknik>
it does
<CalimeroTeknik>
I could've picked one without a C extension, that was confusing I admit
<CalimeroTeknik>
the script https://0x0.st/8mJs.sh solves the issue of `require 'eb'` not working
<weaksauce>
i don't understand your gripe with bundler
<havenwood>
You can also use a Gemfile.lock but add it to your .gitignore file. That's fairly common to see with gems.
<havenwood>
Run `bundle update` to disregard the Gemfile.lock when updating deps.
<CalimeroTeknik>
I'm aware of all of that, yeah, havenwood; the problem is that I also want to access system-side gems, which bundler disables, and that's not an optional feature
Guest35 has joined #ruby
<CalimeroTeknik>
weaksauce, I need `bundle exec`, or the above script, to be able to `require` some gems, but with `bundle exec` (or `require 'bundler/setup'`, which is equivalent) system gems are unavailable
<havenwood>
CalimeroTeknik: If you want to use `bundle exec` you'll be in the context of your `Gemfile.lock`. If you want to add gems to it, do that1
<havenwood>
CalimeroTeknik: You can just remove all `gem` directives from your `Gemfile` and add ^ that to just load all gems. It defies the point of Bundler, but you *can*!
eddof13 has joined #ruby
<havenwood>
It's not something I do, so test it, but you for sure can just add the latest version of all gems to the Gemfile.lock.
<weaksauce>
CalimeroTeknik do you know the exact gems you want?
<weaksauce>
you could do something like rubylsp does and inherit the gemfile