<d_bot>
<mimoo> no lock files by default, no version constraint by default, no local switch by default, etc. there's just too many issues that can arise with the current way of doing things (if I `opam install` something I might mess up my switch, if I forget to create a local switch I destroy my global switch, I can't enforce a specific version of ocaml of version for dependencies with dune, etc.)
<d_bot>
<mimoo> and now if I'm dealing with pins it's another nightmare as well, who knows if the pins are here or not in different environments?
zebrag has quit [Remote host closed the connection]
hendursaga has quit [*.net *.split]
adanwan_ has quit [*.net *.split]
hendursaga has joined #ocaml
gravicappa has joined #ocaml
flux has quit [Quit: Client closed]
<octachron>
Leonidas, I don't really know what you mean by "opam is kinda backward" for dependencies and switches?
olle has joined #ocaml
domq has joined #ocaml
Serpent7776 has joined #ocaml
domq_ has joined #ocaml
domq has quit [Ping timeout: 248 seconds]
domq_ is now known as domq
<d_bot>
<darrenldl> is this about each project having an unshared set of dependencies like rust?
<Leonidas>
octachron: I would want to have opam adhere the dependencies in each switch to the opam file. whereas in reality opam files are more for bootstrapping a switch and what happens afterwards in your switch is up to you
<Leonidas>
esp. if you run `opam upgrade`, then your switch now has whatever versions installed
<Leonidas>
so opam more manages the installed modules in a directory but not really a project. Which is unsurprising, given opam wasn't originally meant to be used that way, local switches came only in opam 2
bartholin has joined #ocaml
<octachron>
Oh, so this is in the local switch mode. I have heard that this mode is not completely ironed out, and esy is clearly much more focused on this use case.
mro has joined #ocaml
glassofethanol has joined #ocaml
mro has quit [Remote host closed the connection]
Haudegen has joined #ocaml
elf_fortrez has joined #ocaml
salkin has joined #ocaml
domq_ has joined #ocaml
domq has quit [Ping timeout: 240 seconds]
domq_ is now known as domq
domq_ has joined #ocaml
domq has quit [Ping timeout: 240 seconds]
domq_ is now known as domq
hendursa1 has joined #ocaml
hendursaga has quit [Ping timeout: 276 seconds]
olle_ has joined #ocaml
mro has joined #ocaml
favonia has quit [Ping timeout: 250 seconds]
salkin has quit [Ping timeout: 248 seconds]
salkin has joined #ocaml
<d_bot>
<dinosaure> I don't really understand the problem about versions and the need to have a local switch. I mean, with a clear release process, I don't live into a nightmare. Of course, pin are needed where you want to develop something but, in this context, your state is definitely not fixed because you explicitly develop on it. Then, you ensure at some point that your "stack" is stable enough (mostly about API) and you launch the release tra
<d_bot>
<dinosaure> And if the API is good enough, only minor versions are needed - so you don't break anything
tengu1 has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mbuf has quit [Ping timeout: 240 seconds]
mbuf has joined #ocaml
PinealGlandOptic has joined #ocaml
mbuf has quit [Ping timeout: 252 seconds]
mbuf has joined #ocaml
jonasbits has quit [Ping timeout: 240 seconds]
elf_fortrez has quit [Ping timeout: 246 seconds]
mro has quit [Remote host closed the connection]
mbuf has quit [Ping timeout: 240 seconds]
mbuf has joined #ocaml
tengu1 has quit [Quit: Client closed]
jonasbits has joined #ocaml
<Leonidas>
Can't say that APIs have been stable, where random stuff breaks in minor versions.
<Leonidas>
So to develop I've basically had to find a solution that works and then add narrow constraints to only allow that.
<Leonidas>
JST v0.10 to v0.11, good luck.
<Leonidas>
(One can claim that even according to semver this is pre-1.0 and all bets are off and that's a fair concern but in practice this is indeed a problem)
<Leonidas>
Even worse is OPAM Repo patching where it depends on the phase of the moon whether mysql packages are installable or not, even if you pin the version. maybe fixed since but i remember having to go back to old projects and fixing things in the docker builds to make them build, which makes me thing that the fact that opam-repo is mutable is an antipattern. But I think opam-repo maintainers have arrived at
<Leonidas>
the same conclusion meanwhile.
<d_bot>
<dinosaure> Hmmhmm, I don't really understand when, for x.y.z, if y is updated, that means that the maintainer broke the API which is "fine"
<d_bot>
<dinosaure> And `opam-repository` is not mutable, I mean, it's a Git repository where any updates are recorded via a commit - and you can decide to be stuck at a certain version
<d_bot>
<dinosaure> And such problem is about JST packages, not OPAM
domq_ has joined #ocaml
domq has quit [Ping timeout: 248 seconds]
domq_ is now known as domq
glassofethanol has quit [Read error: Connection reset by peer]
glassofethanol has joined #ocaml
<Leonidas>
dinosaure: yes, so you have to manually specify in OPAM >= x.y.z && < x.y+1.0 (NPM has special syntax for this, OPAM doesn't) for every package or risk your builds not working next time you recreate a switch.
<Leonidas>
and every user has to know this, whereas npm kinda does pinning by default
<Armael>
a syntax for that is being worked on afaik
<Leonidas>
dinosaure: sure, you can pin a version of opam-repo but then when you want to use an unrelated newer package you have to unpin, do whatever the mysql dance du jour is and pin again.
<Leonidas>
which again, feels like fighting opam and not using it in a straightforward way
<Leonidas>
like that time I made bzr work like git - possible, but the setup was kinda involved and you run into kind of annoyances everywhere for, well, doing it wrong since that's not what the tool was designed for
<Leonidas>
Armael: ah, that's great :-)
<Leonidas>
I also remember there was some work on pinning.
<d_bot>
<dinosaure> Don't get me wrong, OPAM has many issues and it's not perfect or it does not fit for certain usecases but, from what I see, many complaints are not directly related to OPAM - then, may be it's difficult to see the limit between this tool and some others and I agree with that
<d_bot>
<dinosaure> But we should aware about what is the real job of OPAM and, from my experience (and from where the OCaml ecosystem comes from), it seems that OPAM opened a large door for the community to scale up
<Leonidas>
I absolutely agree that OPAM has been nothing but transformative to the OCaml community and this is absolutely fantastic.
<Leonidas>
But I believe there is some fair criticism of the tool. As we see in Rust, good tooling goes a long way and defaults matter so I am sad that OPAM is kinda on the rear-end of PL-specific package managers these days.
<Leonidas>
You can say, OPAM != opam-repository and while that's technically true it is not really helpful.
<Leonidas>
(I also don't want to complain on opam-repo maintainers, they volunteer and do a good job and that's great)
<d_bot>
<mettekou> Anyone here using OCaml for industrial automation? Applications where you'd usually resort to NI software, for instance.
<octachron>
I agree that constructive criticism is fair. Saying that opam is on the rear-end of PL package manages don't really seem fair to me.
<octachron>
At the same time, I recognize that opam fits my use case quite well since I don't use local switches or version locks.
<Leonidas>
octachron: I feel if opam did now what npm did... years ago, last time I used it, I would be overjoyed. Some things aren't possible due to limitations of the ocaml compiler, which is fair, but some things would be nice to have.
<Leonidas>
octachron: at some point I had 32 installations of the ocaml compiler installed in my ~, each of those taking about 15 minutes to build on my 2015 MBP.
<octachron>
What npm did years ago?
<Leonidas>
Automatic lock files
<Leonidas>
Portable npm_modules folder
<octachron>
Yeah, I don't want lock files nor npm_modules folder nor packages that rely on those.
<zozozo>
Leonidas: the problem with specifying really strict dependencies on your project's dependencies is what happens when these really strict deps conflict with that of another package's ?
mro has joined #ocaml
<Leonidas>
(node also supports recursive dependencies but that's not possible in ocaml due to how modules work - sad but that's fair for a language compiler that predates modern package managers by decades)
<octachron>
That is unrelated. Not having recursive modules by default is a design choice.
<Leonidas>
zozozo: sadness, usually. You have to find a solution where dependencies overlap. What we settled was to have strict lower bounds on libraries and no upper bounds, and strict upper and lower bounds on applications.
<zozozo>
but I agree that there are sometimes instability problems, though I'd think trying to better enforce compatibility and respecting semvers would be a better long term solution
<Leonidas>
In NPM that's not a problem because dependencies can have their own versions of their dependencies but realistically that's not an option.
<zozozo>
yeah, but ocaml cannot support linking two versions of the same package currently afaik
<Leonidas>
zozozo: Elm has an interesting solution to semver, where the tooling can determine what's breaking and what is not
<zozozo>
(unless you try and do some really weird automatica wrapping of package into module containing their versions, and add module aliases in each package to unwrap the verion number, but that seems... complex and not great for error messages)
<Leonidas>
Apparently such a thing can't be computed in OCaml, but it would be a neat feature (maybe more on the "cute" side than the "helpful" side but still)
<Leonidas>
zozozo: I agree.
<zozozo>
yeah, there are people with plans on making an alaysis tool to try and determine/verify some notions of compatibility (forward/backward, etc...)
<Leonidas>
I would also be interested in a NPM-like OPAM-repo where people submit packages without review
<zozozo>
but currently in ocaml, adding a new funciton in a module can break some libraries (if they try and implement some of that module type), so basically, any change to an interface is technicnally breaking
<Leonidas>
This is completely possible today
<octachron>
Part of the problem is that the precise answer is "any change is a breaking change for clever enough users"
<Leonidas>
Ah yes exactly, that was the problem.
<Leonidas>
I don't think such a thing would be groundbreaking. I just thought the idea was neat, because it is nice to try other tooling and find delightful things sometimes.
domq has quit [Quit: domq]
<zozozo>
some people have suggested an npm-like repo with pkg names such as @user/pkg-name without needing review
<mclovin>
> I would also be interested in a NPM-like OPAM-repo where people submit packages without review
<mclovin>
sorry
salkin has quit [Ping timeout: 248 seconds]
<zozozo>
but well, that would only make the instability problem worse in my opinion
<zozozo>
I mean, the only thing the review process currently checks is that the package submitted actually builds on a selection of architectures and ocaml versions (that are compatible with the deps of the pkg)
<zozozo>
(and that the new version of a package does not rbeak the build of its revdeps, which actually helps a lot with the stability of builds...)
<Leonidas>
but it also makes things much much slower
<zozozo>
define "much"
<zozozo>
in my experience the most I've had to wait was a few days (maybe a week at most) before one of my packages updates was merged
<Leonidas>
doing an npm release: seconds to minutes, willingness to do a release by packages: high
<d_bot>
<Anurag> i'd probably care about it a lot more if it was difficult co consume git/mercurial/<vcs> repositories with opam. It seems easy enough to go down that route (or make a custom opam repo) that it hasn't been a problem for me in my time with OCaml
<zozozo>
and it was mostly the time it took for all the build checks to complete
<zozozo>
so basically, the thing that is slightly slowing down package release is the minimum of xare that is taken to try and prevent the problem you're complaining about, so i don't see how removing it will help...
<Leonidas>
submitting a release to opam-repo: needs to clone the git repo if you haven't, create a branch with the changes in the folder structure, ceate a PR, wait for CI to finish (in my experience it was often failing for completely unrelated reasons thus adding to the frustrations), deal with review comments, have it merged, wait for the HTTP mirror to catch up. That's usually in the range of hours to days.
<zozozo>
or, you can use opam-release (or dune-release), which can do most of the steps automatically...
<Leonidas>
days vs minutes/seconds is quite a slowdown
<zozozo>
ok, but is it really that much of a problem ?
<Leonidas>
I use dune-release, which is nice, but you still have to deal with the PR
<zozozo>
I mean, you don't release a new version each day/week, so it's a relatively minor duration compared to the life of the package
<Leonidas>
zozozo: I don't know. Alternate question: how much of an improvement over what NPM does is OPAM-Repository? Aka does the review justify the costs?
<zozozo>
I don't know, I've never really used NPM, and I'm pretty satisfied with opam currently
<Leonidas>
We have seen in many places that reducing the hurdles is better.
<Leonidas>
ocaml development picking up due to moving to GitHub as one example
<zozozo>
well... without the hurdle, I'd expect tat a lot more of the packages int he repo would be failing to build in a lot of situations
favonia has joined #ocaml
<Leonidas>
opam providing a package manager over using distribution packages etc.
<zozozo>
(in this specific case of the opam build checks before merging the new package into the repo)
<Leonidas>
zozozo: I don't know. The good thing is that such a solution can be evaluated today without changes to OPAM
<zozozo>
with automated tools, you only need to issue one command (a few seconds), wait for the CI on the opam-repo to finish (that takes a while, but it's not like you need to wait and do nothing while this completes...), and then look at the potential failures
<Leonidas>
add an alternative repository which implements such a scheme and off you go :-)
<zozozo>
well, anyone is welcome to give it a try, ^^
<Leonidas>
zozozo: well, you don't have to wait for CI, but it is not "set it and forget it" because at some point you have to check back.
<zozozo>
indeed
<Leonidas>
Say I have a task "Release version 4 of your ocaml package" I unfortunately can't estimate it, because it can take no time, or it can take days. Which is bad for enterprise adoption
<Leonidas>
Just the fact that releases can take a long time due to things that you have little influence on (e.g. all opam-repository committers are on vacation in August) is just sort of non-optimal
<zozozo>
well, like I said I don't know about NPM, but for other package managers I used (e.g. distribution package managers on linux), I don't think that it's much faster to publish new versions of packegs (I mean, for e.g. debian, that takes years...)
<Leonidas>
We ended up solving it internally by never releaseing anything to OPAM repository and instead creating our own repo with out open source code
mro has quit [Ping timeout: 250 seconds]
<Leonidas>
*our
domq has joined #ocaml
<zozozo>
well, that's certainly a solution, but it limits the usability of your open-source code (from what I can tell, a compromise some companies make is to do the same as you, but periodically make a release on the "official"/public opam-rpeo)
<Leonidas>
Which is kinda the reverse thing from what we as OCaml community want to incentivize :-)
Haudegen has quit [Quit: Bin weg.]
<Leonidas>
Yes, we made releases every now and then, but that was basically dependent on the developers willingness to do so, it could never be included in any official planning because of the uncertainty.
<Leonidas>
And this is a slipperl slope to code-drops like some of the JST stuff
Guest26 has joined #ocaml
<Leonidas>
Of course non-vetted repos like NPM lead to all kinds of other issues, there's no silver bullet.
<Guest26>
hello! i'm trying to use Ocaml for the first time (Arch linux) but I'm stumbling on installing the ocaml-lsp-server already. It tells me no switch is currently set. what should be done there?
<Leonidas>
Guest26: Look into `opam switch create` if you use OPAM
<zozozo>
Guest26: you should first install opam (it's in the officiel arch repositories, so that should be easy)
<Leonidas>
The best supported way is to not use the Arch Linux-provided `ocaml` package, but rather use the `opam` package and let it build and ocaml compiler.
<Guest26>
Yes, opam is installed. I just don't see what I'm supposed to do with these "switches". I just want a default setup...
<Leonidas>
Guest26: A switch is essentially an ocaml installation.
<Leonidas>
Guest26: `opam init`
<Leonidas>
That will set stuff up and create a switch for you :)
<Guest26>
hmm I ran that. maybe something went wrong there then
<Leonidas>
Oh, just noticed that OPAM supports fish. Thats neat
<Guest26>
Leonidas it doesn't seem to work though ;-)
hendursa1 has quit [Quit: hendursa1]
<Leonidas>
Guest26: what do you get from `opam switch list`?
hendursaga has joined #ocaml
<Guest26>
# switch compiler description
<Leonidas>
nothing else?
<Guest26>
no
<Leonidas>
`opam switch create default 4.12.0`
<Leonidas>
`opam switch create default ocaml-base-compiler.4.12.0` <- or this
<octachron>
"opam switch create default" should also work with archlinux's version of opam.
<companion_cube>
octachron: you use opam without local switches?!
<Guest26>
that worked
<octachron>
companion_cube, yes?
<Leonidas>
you can also use opam with the system compiler, but that's incredibly painful and strangely broken
<companion_cube>
octachron: i'm shocked :p
<companion_cube>
that stopped being an option for me years ago, I'd go mad
<companion_cube>
with `opam upg` being basically russian roulette on what package fails to compile
<companion_cube>
anywya, I second most of what Leonidas said
<companion_cube>
I'd be happy if opam did what cargo/npm do
<companion_cube>
and the opam-repo maintainers do a great job, but it still means releases can take arbitrarily long
<Leonidas>
Still have to try cargo :)
<companion_cube>
(for example I've been sitting on a release since last week)
<companion_cube>
apparently cargo is very close to gems
<companion_cube>
but it's like: strong lockfile by default, and local to the project
<octachron>
I have enough global switches between all alpha/beta/released/experimental ocaml versions.
<companion_cube>
one command to do all: `cargo build --release`
<Leonidas>
never used gems, only pypi and that's... truly terrible.
<companion_cube>
heh
<Leonidas>
it's like the Linus quote where for he says that whatever SVN does Git does the opposite because they always do the wrong thing.
<companion_cube>
ouch
<companion_cube>
and yes, the argument that opam enabled growth for OCaml is totally true
<companion_cube>
but we don't know how things would look like if opam was basically npm
<Leonidas>
Exactly. Hopefully I'll find the time to build an npm like thing for OPAM
<Leonidas>
Part of my frustration is that even despite the packages reviewed, upgrading is "basically russian roulette on what package fails to compile"
<companion_cube>
Leonidas: if you have that kind of time, maybe coordinate with the dune team to make dune the npm-like tool? :)
<companion_cube>
after all a dune-project file already contains package descriptions
<Leonidas>
I think it would be an interesting investigation at some point to see the reason why this is the case, maybe there's some common root causes that make this more likely.
<companion_cube>
the reason is bad bounds
<companion_cube>
(because it's impossible to set reasonable bounds anyway)
<Leonidas>
companion_cube: dune slowly turning into cargo ;-)
<companion_cube>
(unless you manually write `>= 1.3 & < 2.0` and hope everybody uses semver)
<companion_cube>
Leonidas: if only 😍
<mclovin>
> (unless you manually write `>= 1.3 & < 2.0` and hope everybody uses semver)
<mclovin>
drom can do that for you
<companion_cube>
the day `dune build @install --profile=release` gets dependencies and builds, I'll swoon
<Leonidas>
companion_cube: heh, I also mentioned exactly this
<Leonidas>
and then msgpack fails because 1.4 and 1.3 aren't compatible. oops.
<companion_cube>
:D wat?
<companion_cube>
ah wait, msgpack, not msgpck
<Leonidas>
yes, the solution is obviously to switch to msgpck :D
* Leonidas
fan of vbmithr software
salkin has joined #ocaml
<companion_cube>
octachron: btw, anecdotically, seems like the "many global switches" is correlated with working on the compiler :)
<companion_cube>
on a small sample size
<theblatte>
Are there going to be more 4.xx releases once 5.0 drops? Just saw that 4.14 is planned (I don't mean to troll I swear ^^)
<octachron>
At the very least, there will be bugfixes releases.
<octachron>
companion_cube, I would expect the correlation to be quite high indeed ... I don't really see another reason to have more than 10 global compiler switches
<theblatte>
octachron: 10 is already a lot ;)
<theblatte>
well I have 10 but only because I haven't GC'd the 9 I no longer use
Haudegen has joined #ocaml
Guest26 has quit [Quit: Client closed]
domq has quit [Quit: domq]
<Corbin>
Leonidas, zozozo, dinosaure: One big trickiness with automatically determining semver from module signatures (or morally similar approaches) is that it's brittle. The Haskell ecosystem shows this off well; they have x.y.z.w semver quadruples and a lot of spuriously-broken packages.
<Corbin>
In general, package composition needs to take place with open-world assumptions, not closed-world assumptions. We should write packages as if their potential composites are unbounded and unknown.
mro has joined #ocaml
gravicappa has quit [Ping timeout: 252 seconds]
zebrag has joined #ocaml
gravicappa has joined #ocaml
waleee has joined #ocaml
glassofethanol has quit [Quit: leaving]
Haudegen has quit [Quit: Bin weg.]
elf_fortrez has joined #ocaml
Anarchos has joined #ocaml
salkin has quit [Ping timeout: 252 seconds]
Tuplanolla has joined #ocaml
mro has quit [Remote host closed the connection]
mbuf has quit [Quit: Leaving]
Haudegen has joined #ocaml
troydm has quit [Ping timeout: 276 seconds]
elf_fortrez has quit [Quit: Client closed]
mro has joined #ocaml
mro has quit [Ping timeout: 250 seconds]
troydm has joined #ocaml
mro has joined #ocaml
Anarchos has quit [Quit: Vision[0.10.3]: i've been blurred!]
mro has quit [Remote host closed the connection]
<d_bot>
<froyo> when is flambda going to be the default code generator btw?
<d_bot>
<froyo> or is there no eta on that
<d_bot>
<octachron> For flambda 1 most probably never. The flambda team has switched to work on flambda 2.
<d_bot>
<froyo> is flambda 1 the one we have with +flambda switches?
<d_bot>
<octachron> Yes
rgrinberg has joined #ocaml
mro has joined #ocaml
mro has quit [Remote host closed the connection]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
salkin has joined #ocaml
gravicappa has quit [Ping timeout: 250 seconds]
average has quit [Quit: Connection closed for inactivity]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
olle_ has quit [Ping timeout: 250 seconds]
rgrinberg has joined #ocaml
mro has joined #ocaml
mro has quit [Remote host closed the connection]
rwmjones_ has joined #ocaml
mal``` has joined #ocaml
Geekingfrog_ has joined #ocaml
wagle_ has joined #ocaml
mro has joined #ocaml
Serpent7776 has quit [Quit: leaving]
haesbaer1 has joined #ocaml
wagle has quit [Read error: Connection reset by peer]