05:16 <mooff> = RUBY_VERSION

05:16 <ruby-eval> => "3.2.0"

06:17 <cxl> Hi all, I'm working on a project where we're using fakefs to mock the filesystem and avoid messing developers' machines while running the test suite. the problem is that fakefs doesn't quite behave like a true filesystem and cannot do locks for example which messes with the Logger and other Ruby stdlib objects. One temporary solution we've found is to run guard+rspec in a docker container and disable fakefs so

06:17 <cxl> that the changes happen in the container but not on the live machine. this has its own issues though and we're looking at alternatives. I'm a bit stumped, mocking the filesystem is just too complicated and hard to maintain, but what other solution is there?

06:49 <mooff> that what extent would it otherwise mess up developers' machines?

06:50 <mooff> * to what extent

06:51 <cxl> mooff: it has a lot of legacy code that write to various places in ~ for example and doesn't clean up after the tests. so at best it litters the home directory, at worst it changes files that might already exist.

06:52 <cxl> s/write/writes

06:54 <cxl> some tests also assume a clean filesystem and will run user ruby files that are supposed to be located in well known places. with fakefs, we manually copy default files there, but without it will either overwrite the user's custom files and/or run the user's files directly instead of the test ones.

06:54 <cxl> so that's not really a test suite people will want to run :D

06:59 <mooff> it sounds like an installer, or some other intentionally system mutating program

06:59 <mooff> in which case, containers to test sound good to me :-)

07:00 <mooff> and / or containers to dev

07:01 <mooff> develop it on Gitpod or Codespaces, using VS Code (Remote)

07:02 <mooff> then your environments are reproducible, destructable

07:07 <cxl> thanks, for now we mount the code dir as a bind mount in the container so that guard can watch the files and run rspec while devs can use their prefered editor on their machines directly.

14:24 <adam12> cxl: I never had great luck with fakefs. I generally just Dir.mktmpdir and do everything on the real filesystem.

14:25 <adam12> cxl: For the Hanami project, they shipped dry-files which supports swappable adapters, with in-memory being one. Might be worth exploring.

15:13 <havenwood> https://www.ruby-lang.org/en/news/2023/05/12/ruby-3-3-0-preview1-released/

15:36 <johnjaye> if you wrote a purely ruby program 10 years ago would it still run today

15:36 <johnjaye> i.e. no imports of external libraries

15:51 <havenwood> johnjaye: It depends. It could but there have been a number of breaking changes in major releases that could make a program of sufficient complexity unlikely to still run.

15:55 <johnjaye> in the sense of adding features or literal breaking changes to existing ones

15:56 <johnjaye> like in c++ they added more keywords, so if you used a variable named a new keyword it wouldn't run

15:58 <johnjaye> as opposed to making an existing thing behave differently which is what i mean

18:33 <kobal> Boa tarde, pessoal :)

18:34 <kobal> Ah sorry, it is a english channel

18:37 <mretka> kobal: There is a portuguese channel in #rubybr

18:40 <kobal> Thanks, mretka