-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ags: 1.8.2 -> 2.2.1 #373562
base: master
Are you sure you want to change the base?
ags: 1.8.2 -> 2.2.1 #373562
Conversation
ldflags = [ | ||
"-s" | ||
"-w" | ||
"-X main.astalGjs=${astal.gjs}/share/astal/gjs" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, because of this single line I wasted an entire day
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also add a release-notes, prompting users to switch to ags_1
if they want to retain compatibility with previous config.
As this is a backwards incompatible change, we should not backport it.
421966a
to
83bd23a
Compare
I'll get to reviewing Friday of next week. (Will be busy for work for the next week till the weekend) If anyone wants to review this and merge, they can go ahead. |
pkgs/by-name/ag/ags/package.nix
Outdated
|
||
meta = { | ||
description = "Scaffolding CLI for Astal+TypeScript"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per https://github.com/NixOS/nixpkgs/pull/373562/files#r1914975896
Something like "Typescript frontend of Widget system powered by Astal"
You can put more details/explain in longDescription
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find your description a bit difficult to follow without any background context. In comparison, the description from upstream seems a bit clearer in this regard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know, "Scaffolding CLI for Astal", doesn't seem to explain its purpose. On a quick search if someone wants a widget system, ags
won't appear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Astal is the widget system, this is just a CLI for it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to revise the description for astal and ags a bit more, check now
9b190b5
to
f3a8a14
Compare
@@ -212,6 +212,8 @@ | |||
[v1.7.0](https://github.com/jtroo/kanata/releases/tag/v1.7.0) | |||
for more information. | |||
|
|||
- `ags` was updated to v2, which is brand new project with different goals. If you still need v1, use `ags_1`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You definitely should explain a bit here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it better now?
writers.writeNu "datadirs" | ||
# nu | ||
'' | ||
$env.XDG_DATA_DIRS | ||
| split row ":" | ||
| filter { $"($in)/gir-1.0" | path exists } | ||
| str join ":" | ||
''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand this, this just gets XDG_DATA_DIRS
at build time and extracts the needed paths from there and puts it in the file?
So this depends on builder's XDG_DATA_DIRS info? Isn't that impure/not reproducible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kind of. Environment variables are secured by Nix sandbox, but this hard-codes library paths to one that are used in build time. However, I am unsure how to get those directories in runtime, and this seems like a bug that should be handled by upstream.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am worried that some dirs/paths from builder/Hydra may not exist in local machine.
@Aylur .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is very much a hack.
I could not find a way to reference the gir-1.0
paths at runtime so I ended up doing this. It is only polluted at build time with references to glib based libraries and even if something leaks into it from the outside environment it does not have any effect as this is only used to generate types for LSPs. It does not have an effect at runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The function that uses this variable is called in ags init
and ags types
, so it is pretty much a runtime thing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Aylur, fmt.Println(os.Getenv("XDG_DATA_DIRS"))
has /nix/store/g8lbqn7mw42pddh57bz9570sfc7fajkf-ags-2.2.1/share
as a first item
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this point I am tempted to @jtojnar for intel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hard to say what is the proper solution without knowing why does the program need access to GIR files at runtime. Typically, those are used at build time to generate bindings modules for static languages, and our gobject-introspection
setup hook already populates XDG_DATA_DIRS
at build time from dependencies:
if [ -d "$1/share/gir-1.0" ]; then | |
addToSearchPath XDG_DATA_DIRS $1/share | |
fi |
As @PerchunPak says, this is not a problem with reproducibility thanks to the sandbox. The main issue would be that it might pick up GIR files pointing to typelibs for build platform when doing a cross-compilation but this software looks complex enough that cross-compilation will probably be broken in multiple different ways anyway so I would not worry about it. You can try strictDeps = true
for peace of mind.
I also do not understand the reason for a custom environment variable rather than just using XDG_DATA_DIRS
(following XDG basedir spec) + GI_GIR_PATH
.
We might want to switch the setup hook to the latter to make GIR paths easier to pick up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jtojnar, this is a build tool, so we need GIR files to generate types while user develops their application.
And it fails with strictDeps = true
. But because ags.bundle
(the thing that developer would use) causes a rebuild of ags
, it should not be a problem (unless many edge-cases, of course).
So, there is no better solution than what we already have...
I like the upstream approach, perhaps we can use that? (Aylur/ags#673) |
https://github.com/Aylur/ags: Scaffolding CLI for Astal+TypeScript
This is basically a complete rewrite (as upstream was rewritten in Go). It is required for #350324, I also built a completely functioning version of hyprpanel using this, so it totally works!
Also, it is almost 1 to 1 copy of the upstream Nix implementation, but this is much more versatile.
Closes #306446
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)CC @FliegendeWurst @foo-dogsquared @JohnRTitor
Add a 👍 reaction to pull requests you find important.