> I don't know why it would take 18 hours, and I don't see a bug report linked.
It seem systematic to the current architecture or developer experience - since the build environment is different than the local environment, there's going to be stuff that leaks through. For example, missing info.rktd dependencies, native dependencies, not pushing changes to dependencies that were on your local machine but not on pkgs.racket-lang.org yet (breaking api changes, additions), sometimes one gets 5xx errors from the frontend so that doesn't help.
When one clicks the "rebuild" button it simply queues the package to be rebuilt. Then you wait and hope everything is working. And come back to address the above issues.
> Then, given Racket's emphasis on cross-platform and backward-compatibility, Matthew's decision to add the semantics support without breaking production for all of the existing users. That seems reasonable and predictable to me.
Bottom line, any language that tries to break away from filesystem semantics of your host OS, is going to cause footguns. Sometimes it's okay to break backwards compatibility.
> What didn't go well? Racket runs on a wide variety of systems. I once experimentally packaged it for plastic OpenWrt routers, and it was straightforward. https://www.neilvandyke.org/racket-openwrt/
My rule is if it isn't packaged in my OS, it doesn't exist in a redistributable form. Racket isn't quite there yet; there's some effort underway to package Racket packages on various operating systems such as Nix, Gentoo, and so on.
> The author got Matthew Flatt and even Matthias Felleisen giving prompt attention to the bug report they linked.
It's true, however a formal process to discuss feedback and next steps for Racket would help folks like myself feel confident in the direction of Racket. Otherwise it's just people on the internet saying "trust me".
> Talk to the developer of that third-party package?
Unfortunately I have found not everyone is interested in fixing their packages. I think this problem might be best fixed by making changes to the package manager to improve the developer experience. My usual work around is to vendor code.
> Units/signatures are ancient, and you probably don't need to use them. Just use the very nice module system (including submodules), and then decide whether you need more.
Is it possible to set up a unloadable plugin architecture without signatures and units?
> There's more than that, including doing spectacular productivity and importance, but there's not many.
I look forward to learning more about these users.
The package server maintains a catalog of available packages.
When you submit a new package, it is more or less immediately
registered in the catalog. This means other users can
try your package quickly.
What takes time is the build server.
The build server builds every package available on the package server.
The build server
- builds the package in a sandboxed environment
- builds documentation
This takes time, since packages can refer to each other.
The advantage is that the documentation can use scope information
to link all identifiers to the correct sentry in the docs.
It would be nice for some improvements though:
- getting a mail when the build is done
- incremental build of packages that no other packages rely on
It seem systematic to the current architecture or developer experience - since the build environment is different than the local environment, there's going to be stuff that leaks through. For example, missing info.rktd dependencies, native dependencies, not pushing changes to dependencies that were on your local machine but not on pkgs.racket-lang.org yet (breaking api changes, additions), sometimes one gets 5xx errors from the frontend so that doesn't help.
When one clicks the "rebuild" button it simply queues the package to be rebuilt. Then you wait and hope everything is working. And come back to address the above issues.
> Then, given Racket's emphasis on cross-platform and backward-compatibility, Matthew's decision to add the semantics support without breaking production for all of the existing users. That seems reasonable and predictable to me.
Bottom line, any language that tries to break away from filesystem semantics of your host OS, is going to cause footguns. Sometimes it's okay to break backwards compatibility.
> What didn't go well? Racket runs on a wide variety of systems. I once experimentally packaged it for plastic OpenWrt routers, and it was straightforward. https://www.neilvandyke.org/racket-openwrt/
My rule is if it isn't packaged in my OS, it doesn't exist in a redistributable form. Racket isn't quite there yet; there's some effort underway to package Racket packages on various operating systems such as Nix, Gentoo, and so on.
> The author got Matthew Flatt and even Matthias Felleisen giving prompt attention to the bug report they linked.
It's true, however a formal process to discuss feedback and next steps for Racket would help folks like myself feel confident in the direction of Racket. Otherwise it's just people on the internet saying "trust me".
> Talk to the developer of that third-party package?
Unfortunately I have found not everyone is interested in fixing their packages. I think this problem might be best fixed by making changes to the package manager to improve the developer experience. My usual work around is to vendor code.
> Units/signatures are ancient, and you probably don't need to use them. Just use the very nice module system (including submodules), and then decide whether you need more.
Is it possible to set up a unloadable plugin architecture without signatures and units?
> There's more than that, including doing spectacular productivity and importance, but there's not many.
I look forward to learning more about these users.