On Thursday, April 30, 2020 at 3:59:49 PM UTC+8, Laurent wrote: > > Alex, that looks like an interesting workflow. Maybe worth a blog post? ;) >
Well, it took longer than I anticipated, but here it is: https://alex-hhh.github.io/2020/05/dependency-management-in-racket-applications.html I understand that everyone has a different workflow and my workflow will not be directly applicable to them, but hopefully a few ideas can be re-used. I also tried to explain what I would like from a "dependency management" solution. Alex. > > On Thu, Apr 30, 2020 at 12:11 AM Alex Harsanyi <[email protected] > <javascript:>> wrote: > >> >> You could both send packages to the package catalog and instruct your >> users to use a different package source if they wish to use old versions. >> I don't see these two options in conflict with each other. >> >> As an application writer, I am on the other side of this problem, by >> depending on other packages. Having limited time to work on my project I >> want to upgrade package dependencies at my own pace. The solution I found >> is to use git submodules and add each package as a submodule to my >> application. I construct a catalog of these packages, at an exact git >> commit, and simply run a raco pkg install, knowing that the exact version >> that I want will be there. From time to time, I update these submodules >> and allow some time for fixing any problems that might result from these >> updates. This has worked reasonably well so far, and I can reliably >> reconstruct older versions of the application knowing that all dependencies >> will be correct for that old version. >> >> For my part, for any packages that my application depends on, their >> authors can make any breaking changes they want, as this will not >> immediately break my application. At a later date I can review these >> changes, update my application and move to the new version. >> >> The only downside is that installed packages are at "user scope" rather >> than "application scope" so once installed from the git submodules, that >> package becomes available to all applications on my computer. So far this >> has not been a real issue, although I had to uninstall, switch catalogs and >> re-install a few times. >> >> I personally regard pkgs.racket-lang.org as the source for the latest >> package versions, for users which just started using the package. Users who >> need precise versioning, can always setup their own package catalogs (i >> discovered that it is a really simple process) >> >> Alex. >> >> >> On Thursday, April 30, 2020 at 12:47:25 AM UTC+8, Sage Gerard wrote: >>> >>> April 9th in the #general Slack channel taught me that there was no >>> clean way to >>> release a breaking change in a package. I'm open to working on version >>> pinning >>> support in raco pkg provided that a maintainer can walk me through some >>> code. >>> >>> In the meantime, as much as I appreciate the efforts made in the current >>> system, >>> I'm considering stopping my contributions to the package catalog until >>> further notice. >>> I'm open to submitting packages if I am confident in their longevity, >>> but I don't want >>> to end up in the position I've been in for the last few weeks when >>> planning a release. >>> That position being an inability to release an edition that is not in >>> some way "aware" >>> of a prior edition. In my view, changing the package/collection name is >>> an >>> example of that problem, not a solution to it. >>> >>> I'm considering asking my users to specify different package sources in >>> their info.rkt >>> files when dealing with my work. Before I commit to that decision, I >>> wanted to tap into >>> those of you who have already been here. How have you handled breaking >>> changes >>> for your projects? How have you communicated with your users to make >>> sure they >>> were adequately prepared? Am I being too black-and-white about this? >>> >>> *~slg* >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/b3b54ccf-b4f1-425e-802a-110d5ac26591%40googlegroups.com >> >> <https://groups.google.com/d/msgid/racket-users/b3b54ccf-b4f1-425e-802a-110d5ac26591%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/ddfa63d5-974b-43af-969c-df147470920f%40googlegroups.com.
