01:05 <quazimodo> Hello

01:06 <quazimodo> i'm having trouble understanding how to init a new project, how do you generate the packages's .opam file?

01:07 <quazimodo> when I use `opam pin .` & go through the process it doesn't actually create any .opam file

01:20 <quazimodo> man getting ocaml project started & compiling is like pulling teeth :/

01:21 <quazimodo> what is a 'switch configuragiot'

01:44 <d_bot> <beheddard> dune init creates an empty opam file at the least doesn't it?

02:09 <quazimodo> it's completely empty :/

02:09 <quazimodo> it put 'main.ml' in the bin/ directory :/

02:09 <quazimodo> why is everything so weird!

02:10 <d_bot> <rgrinberg> Try https://github.com/tmattio/spin

02:11 <quazimodo> `bin - Native project containing a binary.` that is such an odd choice

02:11 <quazimodo> or maybe it's not

02:11 <quazimodo> nvm i'm panicking too early

02:29 <quazimodo> he following dependencies couldn't be met: - spin -> reason -> ocaml < 4.11

02:30 <quazimodo> ocaml --version: The OCaml toplevel, version 4.11.1

02:31 <quazimodo> what does that even mean

02:31 <quazimodo> it wants to downgrade my ocaml

02:33 <companion_cube> reason is not compatible with 4.11

02:33 <companion_cube> for some reason

02:34 <quazimodo> this onboarding is difinitely a reason why ocmal isn't more popular ... my god so many ways for the damn system installation to break

02:34 <quazimodo> im a bloody tech lead i'm not a moron... this is making me feel stupid

02:35 <companion_cube> I have no idea what spin is

02:35 <dash> you lose your edge if you don't do stuff to make yourself feel stupid from time to time

02:36 <quazimodo> dash: believe me i'm no where near losing my edge... my work has me on something new damn near every day

02:36 <dash> the reasonml/ocaml/npm/dune constellation has plenty of room for confusion, being the intersection of two and a half different languages

02:36 <quazimodo> why is dune written in AST ...

02:37 <companion_cube> AST?

02:37 <quazimodo> dune appears to just be an abstract syntax tree, like a lisp

02:37 <companion_cube> https://github.com/ocaml/dune <--- dune is written mostly in OCaml

02:37 <quazimodo> well, a lisp list

02:37 <quazimodo> sorry, the dune files

02:37 <companion_cube> you mean, the dune files? S-expressions are pretty nice

02:37 <companion_cube> beats alternatives

02:37 <quazimodo> except the entire programming world just wants json :/

02:38 <quazimodo> i cut my teeth on lisp ... even I wouldn't have use sexps for what should be a json document

02:38 <quazimodo> the thinking here is so wild lol

02:42 <quazimodo> https://medium.com/@bobbypriambodo/lightweight-ocaml-docker-images-with-multi-stage-builds-f7a060c7fce4

02:42 <quazimodo> this article has been more helpful than the entire body of ocaml/opam/dune docs i've read so far

02:44 <quazimodo> what's better

02:44 <quazimodo> alcotest or rely

02:44 <d_bot> <rgrinberg> alcotest

02:45 <quazimodo> i'm accustomed to ruby's rspec style

02:45 <d_bot> <rgrinberg> As a rule of thumb, if a project is more related to reason it's much more likely to be unstable, experimental, in flux

02:46 <d_bot> <rgrinberg> So you should avoid reason related stuff until you know what you're doing

02:46 <quazimodo> is rely a reason thing?

02:46 <d_bot> <rgrinberg> Yeah

02:46 <quazimodo> ah

02:46 <quazimodo> spin appears to have done a thing, that's nice

02:47 <d_bot> <rgrinberg> Spin is a nice project from the reason world. It would be much more usable if it didn't depend on reason though

02:48 <quazimodo> yeah i'm running all this stuff in docker

02:49 <quazimodo> kinda wish we didn't use 'bin' as a directory for code & compiled executables though

02:49 <quazimodo> so weird

02:49 <quazimodo> what's this mli file

02:51 <d_bot> <rgrinberg> LIke a header file

02:51 <quazimodo> do I maintain these or are they generated ?

02:51 <d_bot> <rgrinberg> You maintain them. But they are optional. You can safely delete it

02:52 <quazimodo> is it to act as ahint to developers/compiler what the public stuff of a module should be?

02:55 <d_bot> <rgrinberg> Mainly. If there's an mli, it defines the public interface of the module

02:55 <d_bot> <rgrinberg> There are some other subtle benefits though

02:56 <companion_cube> typically that's where you put the docstrings

02:58 <quazimodo> ok

02:59 <companion_cube> (also, why would the world want json for the build? s-exprs, in this particular case, are just nicer, mostly because of comments)

02:59 <quazimodo> opam depext seems nice

02:59 <quazimodo> this thing is for build time external deps as well as runtime ones right?

03:01 <companion_cube> yes, if you depend on a C library, typically, you can install them with `opam depext`

03:01 <companion_cube> (especially in CI)

03:13 <quazimodo> fuuuucking finally it can run

03:26 <quazimodo> how does depext make a distinction between runtime deps & build time deps?

03:46 <quazimodo> How to reference a function 'do_stuff' in lib/foo/bar.ml ?

03:46 <quazimodo> does directory matterS

03:47 <quazimodo> ?

04:02 <companion_cube> yep

04:14 <quazimodo> yeah i dont get it at all lol

04:14 <quazimodo> i'm struggling to reference `message = "hi"` in lib/foo/bar.ml from lib/main.ml

04:14 <quazimodo> it shouldn't be this hard!

04:35 <companion_cube> these are two separate libs, right?

04:41 <quazimodo> no i'm just trying to organise my code, why do they need to be separate libraries?

04:42 <companion_cube> dune mandates that one library = one directory

04:43 <quazimodo> i am getting sad

04:48 <companion_cube> why?

04:48 <companion_cube> in a lot of languages, layout of files matters

05:26 <quazimodo> companion_cube: apparently not ocaml

05:26 <quazimodo> can I use this with dune: https://github.com/Octachron/codept

05:27 <quazimodo> the '-nested' option is what i'm interested in

11:37 <quazimodo> sorry for being a drama queen earlier, and probably again soon

11:37 <quazimodo> i still haven't quite figured out how (i'm using opam and dune) to have a structured lib directory. I've made a gist with a basic idea of what I mean

11:37 <quazimodo> https://gist.github.com/siassaj/c85ceebda7273cb31f100d357c16aed7

11:38 <quazimodo> given these files... how would I reference Controllers.Users from main.ml, for example. Would there even be a Controllers.Users or would we be doing something else

12:05 <d_bot> <craigfe> You typically need `dune` files in every directory that contains code, so you'd need one in the root and one in `controllers/`

12:06 <d_bot> <craigfe> Then `controllers/dune` defines a library with `(library ...)` that the root dune file depends on inside its corresponding `(libraries ...)` stanza

12:11 <d_bot> <craigfe> (at that point, the definitions of `controllers/users.ml` are referenced by `Controllers.Users` as you suggest)

12:23 <d_bot> <rgrinberg> Be careful of doing it this way however. You will make it very easy to introduce circular dependencies which OCaml forbids. Another option is to to use `(include_subdirs unqualified)` and forego the pretty names.

13:11 <quazimodo> im not sure how to reply to each of you separately

13:12 <quazimodo> craigfe: and what happens when you have something like Controllers.Api.V1.Users

13:12 <quazimodo> with the path being controllers/api/v1/users.ml

13:22 <quazimodo> same thing, dune will allow?

13:32 <quazimodo> rgrinberg: I'm trying to understand how do you structure a project with a team of 10 devs and many nested parts/concerns

13:33 <quazimodo> rgrinberg: do you expect everything to be super flat?

13:47 <d_bot> <craigfe> quazimodo: The fundamental unit of shared code w.r.t. Dune is a library, which is expected to exist in a single directory. rginberg's suggestion of `(include_subdirs unqualified)` effectively causes Dune to see all files in the subtree as being part of the same directory, and so it works if all you care about is your FS structure, but does not reflect that FS structure in the namespacing of modules in the code.

13:47 <d_bot> <EduardoRFS> Not rgrinberg, but being flat is always a good idea

13:53 <d_bot> <craigfe> quazimodo: If you want to reflect arbitrary FS structure as nesting of module namespaces, you need to manually specify Dune rules that make it so. (In this case, `api/v1/dune` might define a `controllers-api.v1` library, for instance, which would then be re-exported as part of a parent library.) OCaml projects tend not to be structured this way, preferring a combination of the namespacing tools that exist in the language and mult

13:54 <d_bot> <craigfe> If you want an example of a large Dune repository, https://gitlab.com/tezos/tezos/ does this. (although it has its own idiosyncrasies)

13:54 <d_bot> <craigfe> Another example would be Dune itself.

13:55 <d_bot> <craigfe> Both of these go the route of `src/<library>/*.ml` with more granular namespacing reflected in the code rather than the file-system.

15:03 <rain1> https://bpa.st/YUFA I got this error trying to build opam

15:04 <rain1> https://github.com/ocaml/opam#compiling-without-ocaml also make cold said cold is not a target