Jump to content

Workflow Environment Variables are randomly not read properly


Recommended Posts

I recently upgraded to Alfred 5, and noticed that in several workflows that worked flawlessly in Alfred 4, certain features stopped working in Alfred 5. After a lot of trial and error (since I develop some of the workflows), I figured out that the issue seems to be connected to the reading of workflow variables. The errors look like reading a variable results in an empty string (even if the variable itself does have a non-empty value), or some older value of the variable is inputted. (and even when manually changing the value, when running a script using those variables, it's still the old value that is returned.)

 

The issue does occur with several environment variables from different workflows, but not all of them. Unfortunately, I haven't been able to figure out exactly what the common denominator is. An example for the issue, with the the PDF annotation extractor workflow. The list filter shows the current values of the variables, and 3 out of 6 variables have wrong values. Changing those values – either via workflow, or manually – also has no effect.

 

 

 

image.thumb.png.fb43af2b163cbae73bb913a7f91f0e34.png

 

1311212336_Pastedimage2022-07-1516_23_43.thumb.png.cac0b5692e6cfeb25f6a10ebc6177b46.png

 

718395953_Pastedimage2022-07-1516_25_49.png.b6bf8d137e2eb4c893ef03da98f8a311.png

Edited by pseudometa
Link to comment
Share on other sites

Great that you bring that up. Yesterday I figured out a similar issue in one of my workflow. 

 

WF steps that I set up:

 

Screenshot_2022-07-15_at_17_14_23.thumb.png.2d19d172cba7b95352dbe06862ccc8b7.png

 

I start the wf with (1) and (2) sets the variable "path". It will be identified as directory in file system and go through DIR to call external. Call External will start at (3) (with Pass variable enabled) and (3) receive "path" variable. Debugger shows it is available. I implemented (4) to write "path" into variable "my_path". Without (4) , (1) cannot read "path".

 

It seems it is the same issue, but I am not certain. 

Link to comment
Share on other sites

@pseudometa The screenshots are confusing, as there is tons of information but you don’t specify what is relevant. I recognise your Workflow but am not familiar with it in usage. The screenshot shows aconf but that doesn’t look like an available Keyword so I don’t know what it’s referring to.

 

Can you share which Workflows work or don’t, and which variables work or don’t? Preferably simple Workflows, so they can be chopped to simple testable use cases.

 

@Acidham That Workflow looks simple enough; could you share it?

Link to comment
Share on other sites

Posted (edited)

@vitor The workflow in question is actually not the citation picker, but the PDF annotation extractor

 

I tested it, you can reproduce the issue directly by cloning the repo and then running the keyword "aconf". (Cloning the repo has the advantage that it gets you the version which includes the settings displayed in the screenshot already.)

git clone git@github.com:chrisgrieser/pdf-annotation-extractor-alfred.git

 

I tested it exactly with the version you get via cloning. After downgrading to Alfred 4 and using exactly the same preferences, the issue disappears again.

 

And, here are the same three screenshots with rectangles highlighting exactly the parts which do not match.

aconf keyword.png

list filter.png

workflow environment.png

Edited by pseudometa
Link to comment
Share on other sites

1 hour ago, vitor said:

@pseudometa The screenshots are confusing, as there is tons of information but you don’t specify what is relevant. I recognise your Workflow but am not familiar with it in usage. The screenshot shows aconf but that doesn’t look like an available Keyword so I don’t know what it’s referring to.

 

Can you share which Workflows work or don’t, and which variables work or don’t? Preferably simple Workflows, so they can be chopped to simple testable use cases.

 

@Acidham That Workflow looks simple enough; could you share it?

@vitor

I did not commit the new version. Therefore, this one should not work in A5: https://github.com/Acidham/alfred-vscode-workspace-explorer

 

You can download Workaround version here: https://www.dropbox.com/s/5wvxv5977xl0695/VSCode Workspace Explorer.alfredworkflow?dl=0 

(this version includes step4 by writing "path" variable into "my_path")

Link to comment
Share on other sites

35 minutes ago, pseudometa said:

The workflow in question is actually not the citation picker, but the PDF annotation extractor.

 

They’re visually quite consistent!


Thank you for the new annotated screenshots. The issue is you have both Workflow Environment Variables and User Configuration set up at the same time, with the same variable names. So they’re overriding each other. Whatever you set as User Configuration, you should remove from Workflow Environment Variables.


Note that with User Configuration, you no longer have to worry about “don’t export” in variables. Instead, Alfred saves those to a prefs.plist at the root at the Workflow, which you can e.g. add to gitignore.

 

Will open an issue internally to discuss ways of making the conflict more obvious.

 

@Acidham Your issue will thus be a different one. Unclear from your last message, but do you mean that setting path to my_path fixes it? Indeed you should not be setting path as a general variable because that could lead to breakage in scripts.

Link to comment
Share on other sites

6 minutes ago, vitor said:

 

@Acidham Your issue will thus be a different one. Unclear from your last message, but do you mean that setting path to my_path fixes it? Indeed you should not be setting path as a general variable because that could lead to breakage in scripts.

 

Ok, that is what I initially thought, but then I thought path != PATH, and it should work. Maybe it would be good to document that, in case it is not documented. ;)

 

Anyhow, good news, no BUG! Thanks for the help @vitor

Link to comment
Share on other sites

4 minutes ago, Acidham said:

that is what I initially thought, but then I thought path != PATH

 

Curiously, I bumped into that exact question some days ago and confirmed it at the time. Haven’t had the chance to investigate the (historical?) reason yet. Bash and Zsh work differently here.

 

Edited by vitor
Link to comment
Share on other sites

23 minutes ago, vitor said:

 

They’re visually quite consistent!


Thank you for the new annotated screenshots. The issue is you have both Workflow Environment Variables and User Configuration set up at the same time, with the same variable names. So they’re overriding each other. Whatever you set as User Configuration, you should remove from Workflow Environment Variables.


Note that with User Configuration, you no longer have to worry about “don’t export” in variables. Instead, Alfred saves those to a prefs.plist at the root at the Workflow, which you can e.g. add to gitignore.

 

Will open an issue internally to discuss ways of making the conflict more obvious.

 

@Acidham Your issue will thus be a different one. Unclear from your last message, but do you mean that setting path to my_path fixes it? Indeed you should not be setting path as a general variable because that could lead to breakage in scripts.

 

Oh I see. I thought the user configuration was simply a more accessible way to change environment variables, I didn't get that they were defining variables on their own. Thanks.

Link to comment
Share on other sites

3 minutes ago, pseudometa said:

I thought the user configuration was simply a more accessible way to change environment variables

 

This is a question I have. What's the point of the Environment Variables panel now we have the User Configuration?

Link to comment
Share on other sites

@xilopaint I assume this for backwards compatibility.

 

However, I am wondering how one should deal with the parallel functionality of environment variables and user configuration. Like, If I wanted to offer user configuration for users of Alfred 5, I would have to remove the workflow environment variables for users of Alfred 4. If I was using different variable names, I would have to add a whole lot of code branching depending on Alfred version number. If I would just say that from a certain version on, my Alfred workflows are only compatible with Alfred 5, then I have the problem that the autoupdater will also update the workflow for everyone still on Alfred 4... 🙈

Link to comment
Share on other sites

@xilopaint Backwards compatibility, as mentioned, is an important reason. But going forward you may still wish to use the panel to set values you want to be accessible globally throughout the Workflow but not necessarily changed by users. For example, Nitter has multiple instances which come and go. The API is the same, only the host changes. By setting it as a Workflow Environment Variable, you can easily swap it for another instance without having to alter the code in the Workflow (likely in multiple places) or exposing it directly to users who might change the value and break the Workflow.

 

@pseudometa Check version 2022.2 of Alias Homebrew Apps., specifically the coloured objects at the end. It detects the current major Alfred version and branches to each update path separately. You don’t have to set anything on the v4 leg, though. Also, note each Alfred version understands the .alfredXworkflow extension for the current version and below. Meaning Alfred 5 opens .alfred5workflow but Alfred 4 doesn’t. I think @deanishe’s old library, which @xilopaint is porting to Python 3, had support for that. I prefer the manual branching, but use whatever makes sense for you.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...