Re: packaging Typst? [or other rust apps that have several internal crates]
Thank you Sergio On 01/11/2023 14:04, Sergio Pastor Pérez wrote: Hi, Alexis. `typst` seems to use a structure that relies on multiple smaller crates. There has been some discussions over the IRC on how this could be packaged using the current cargo build system. Yes I asked the question there as I figured this was a more general approach to trying to figure out how to package this kind of app. I'll also add what I mentioned on irc, that packaging helix [1] would be pretty similar also. Maybe someone in the rust team would be willing to look at that and/or try to mentor me into looking at rust related packaging. The discussion where I participated revolved around `pathfinder` (https://github.com/servo/pathfinder). Unfortunately there has not been any consensus on what could be done to package this kind of structure. I'm hoping that someone has some ideas on how to approach the issue. Thanks. Sergio. Alexis Simon writes: Hi, Is anyone looking into packaging Typst (https://github.com/typst/typst)? This is a very promising Latex alternative. If no one is doing that I could try to investigate packaging it but I would need some help on where to start. This is a rust app but not available on crates.io. Thanks! Alexis One thing I don't really understand right now in the cargo build system is how dependencies are managed compared to other build systems. If anyone has a beginner blog post or tutorial on that please share. Cheers, Alexis [1] https://github.com/helix-editor/helix
Re: Further work on WebAssembly target for Guix
Hi Zamfofex On Wed, Nov 01 2023, zamfofex wrote: > Please do let me know what you think about it! I’m open for suggestions and > requests, if anyone feels like this is an interesting endeavor. > > This is a follow‐up to > https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00458.html I read your follow-up with the same enthusiasm as your original. Over time, WASM runtimes may become so good that they will replace the internal engines of GNU Guile, Emacs Lisp and other interpreted languages. Designing a new interpreted language will become easier. The effect could be similar to how LLVM enabled new compiled languages like Zig. While WASM runtimes are currently like the Wild West, I find it conceivable that WASM performance could approach half or more of native binaries on some architectures. [1] Because many people like using browsers, those browsers may eventually try to encapsulate the operating system in a way that's similar to what Emacs and Lisp Machine fans have wanted to do for decades. Truth be told, GNU Guix has also been described as a way to bring the Emacs philosopy to the operating system level. Alas, I believe GNU Guix will eventually run *inside* of Emacs rather than the other way around, as it is currently, The reason is that the encapsulation efforts in the browser wars will eventually also engulf Emacs and then pitch the browsers against Emacs in search of dominance in the user interface experience. It will be like GNOME/Sway vs Ratpoison/StumpWM/XMonad currently, but on a bigger level! In either scenario, the WASM build target will skyrocket in popularity everywhere. A WASM target for GNU Guix is very valuable. Thank you for your hard work! Kind regards Felix [1] https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00458.html
Re: Proposal: Differentiate products more clearly (Cycle 01)
Hi pinoaffe, El 12/10/23 a las 20:30, pinoaffe escribió: Hi! I think it's important to clarify what Guix is (and I really like your mockups/some of the concrete proposed changes), but I don't quite agree with the idea behind your proposal. I think it would be more useful to produce and maintain a clear list of what guix can do than to bifurcate guix into a package manager and an operating system, especially since many of the aspects of Guix don't cleanly fall in either of those two categories. In this proposal, that clear list of what Guix can do would be the feature list, linked early in the home page, right after Guix's definition. The features list already exists in the manual, but I think it could provide more information. Regarding the separation of both products, as I see it, it already exists, it is just that it is not that clear. There are separate downloads for both products and the manual, for example, has specific sections for the package manager and the operating system. Now, I do agree that "package manager" and "operating system" don't quite make potential users picture the whole range of features provided by Guix... Would you still disagree with the differentiation of both products if the definition of Guix changed from "package manager" to, say, "a tool for reproducible deployment at every level of scale", as Ricardo suggest (https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00142.html)? Or something along those lines? Luis Felipe writes: This is a proposal to help differentiate Guix, the package manager, from Guix System. Guix is (in my opinion) a (set of) tool(s) with a broad set of features centered around reproducibly managing software/computers. Some of those features enable you to set up and manage entire GNU/linux systems, some even enable you to do so remotely, others enable you to configure homedirs, to set up containers, to reproducibly build software or to manage your computational environment. In my view, these functions are all quite tightly intertwined, and I don't think it makes sense to categorize Guix features as belonging to either the package management or the operating system side of things. Since guix packages kernels, since it can install and configure bootloaders, and since it can manage/configure system-wide services, it can be used as an "operating system". I think that it is important to - clearly communicate the various different things guix can be used for, - emphasize how guix can be used with other operating systems and tools, - and to show how these various features relate to each other. Background: As far as I understand, Guix was supposed to be GNU's package manager, and GNU was supposed to be the operating system: two products with two different websites. Unfortunatelly, that didn't happen and the Guix website became the home for two products: Guix, the package manager, and Guix System, a distribution of the GNU operating system. Guix has become a package manager developed as part of and endorsed by the GNU project. GNU (to me) is an operating system family with significant overlap with the Linux family, and Guix falls somewhere in between as a distribution of both. I personally don't see this as a failure, but I guess that this largely a matter of perspective and beside the point. Since then, both products have been presented almost as a single one in the website. Probably as a result of this some people call both products by the same name (Guix), and some other people don't understand what «Guix» is by skimming through the home page. While there is indeed confusion, presenting Guix as just an operating system and a package manager would not clear that up (in my opinion), - since ~guix deploy~ is related to managing operating systems, but is not really a function of the operating system itself, - since ~guix home~ is best used on an entire system managed by guix but can IIRC also be used on foreign distros, - since ~guix shell~ doesn't really fall into either package management or operating system territory, etc. I may be misreading you, but I think your points are in line with the idea of changing the definition of Guix to better communicate its many other features, instead of simply calling it a "package manager". If I read you correctly, I think having an additional presentation and definition for the Guix System (the OS), as suggested in this proposal, would not conflict with a possible change to Guix's definition. [...] The following mockups illustrate the proposed changes. You can start in the Home page mockup, and click links to go to the other mockups. If your browser doesn't support PDF, you can find a PNG version of each mockup in the same URL paths (simply change the "pdf" extension to "png"). · Resource: Home page Path: https://guix.gnu.org/ Mockup: https://luis-felipe.gitlab.io/downloads/temp/guix-website-2023-09-21-LF/home-page.pdf · Resource: Download
Re: Better support remote deployment
Hi Ricardo, On Wed, Nov 01 2023, Ricardo Wurmus wrote: > What do you think about changing “guix package” and/or “guix copy” to > better support deployment of remote profiles? As someone who uses 'guix deploy' all the time. I believe remote administration is one of our core strengths and selling points. Other remote administration tools like Ansible or Puppet are probably no longer needed when using GNU Guix System. I currently have only x86_64 equipment deployed, so there is no cross-building happening in my setup. Is that the main purpose of your proposal? Your effort to extend Guix's spectacular remote capabilities to other parts of of the Guix package manager seems exceptionally valuable to me. Thank you for working on it! Kind regards Felix
Better support remote deployment
Hi Guix, I build software locally and deploy the result to a remote system with “guix copy”. This works pretty well but has a few rough edges: 1. “guix build -m manifest.scm” does not generate a profile. It only builds the list of packages. To build a profile from a manifest file we need to resort to something like this: guix shell -m $(PWD)/etc/container-server-manifest.scm -- sh -c 'echo $GUIX_ENVIRONMENT' 2. “guix package” cannot install an existing profile store item as the current generation of the profile. It can, however, install individual package items into a profile. 3. “guix package --remove” does not support regular expressions, so removing packages that were installed with “guix install /gnu/store/…” cannot easily be removed. Because of these limitations I cannot make use of a Guix profile symlink forest on the target system. Instead I build a profile locally (with the “guix shell” trick above), copy it to the remote with “guix copy --to=remote /gnu/store/…-profile”, and then link that profile to a fixed location on the remote system. I would like to change this workflow so that I can benefit from roll backs without having to manually mess with symlinks. What do you think about changing “guix package” and/or “guix copy” to better support deployment of remote profiles? -- Ricardo
Further work on WebAssembly target for Guix
Hello, Guix! For anyone who might have had interest in it last time, I have continued working on my WebAssembly cross‐compilation target for Guix, now with support for the Meson and CMake build systems and also preliminary support for C++. Once again, it’s in fairly early stages currently, but it is able to compile fmtlib and GMP. My hope was to compile daikichi, but it seems it uses various constructs that are not supported yet (e.g. ‘#include ’ is not supported). See my changes on https://git.sr.ht/~zamfofex/guix-wasm To try it out, run the following command. (Though note that it will compile Clang from source!) ./pre-inst-env guix build --target=wasm32-unknown-wasi fmt-wasm gmp-wasm Currently, there are WebAssembly‐specific packages and build systems for fmtlib and GMP in order to avoid a world rebuild. Please do let me know what you think about it! I’m open for suggestions and requests, if anyone feels like this is an interesting endeavor. This is a follow‐up to https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00458.html
