pixelgeek

This sounds as if it might be similar to an issue I ran into recently.

Victor had some links to ways to solve my problem that might help you out

3 hours ago, vitor said:

That is not a concern with Alfred because every workflow runs in a pristine environment, as if you had started fresh all your shell configuration.

 

I see the difference now. Thanks for clarifying that. I'll play around with the Workflow and see if I can get it working the way you suggested. 

So I did some poking around. 

It appears that Alfred's version of Python is coming from `/Library/Developer/CommandLineTools/usr/bin` and is running Python 3.9

Is there any way to get it to run from where I have Python installed or is that not practical?

3 hours ago, vitor said:

To include a Python package with a workflow, use the --target option and set PYTHONPATH. StackOverflow has other options.

That may have been good advice some time ago but no-one suggests that you do that anymore. That link is to a 13 year old article and modifying the PYTHONPATH is a fairly big no-no now. When I develop python apps I use a .venv but I can't do that for something that runs in Alfred.

3 hours ago, vitor said:

Do you mean you set the language to External Script, or are you running it from a shell?

It is set to External Script.

It runs correctly when I do that but if I put the same code in the Script Filter I get the library error. The problem is solved in that I have code that runs but I don't understand how Alfred appears to be accessing a different version of Python or one that is in a different location. 

If anyone is interested, I posted a few comments about the update on my blog

https://whatiswrongwithyourdog.netlify.app/posts/hugoupdate/

I am the author of the Hugo Workflow in this thread: 

The Workflow is mirrored at

https://github.com/lolbat/Alfred-Hugo-Workflow

The README has screenshots of the Workflow in use as well as the requirements. Please let me know if you need any other screenshots.

The Workflow requires Python3 as well as the python-frontmatter library.

Configuration info is also in the README. 

I have posted a new version of my Hugo SSG Workflow. Hugo is a Static Site Generator written in Go that you can use to set up a static HTML website or blog. 

The Hugo Workflow has several commands that you can use to make it easier to create and edit content as well as start and stop the integrated web server included in Hugo so you can preview your site and content.

The Workflow is available at:

https://codeberg.org/lolbat/Alfred-Hugo

and is also mirrored at

https://github.com/lolbat/Alfred-Hugo-Workflow

The Workflow currently has seven different commands built into it.

1. Add: Add a new file
2. Edit: Edit an existing file
3. Start: Start the Hugo server
4. Start - drafts: Start the Hugo server with --buildDrafts enabled
5. Stop: Stop the Hugo server
6. Date: Get a date in the Go format to use in the YAML frontmatter of content.
7. Drafts: List all of the content that are still Drafts

If you have seen this Workflow previously the changes in the current version are:

v1.0

The feature complete version. With bonus Drafts command. .

Changes

* Added Drafts command to show any content that is still marked as a Draft post. 
* Fixed Edit command to run correctly.
* Actually fixed the Start Server command.
* Rewrote the Edit python code to use the Paths library.
* Added requirement to have the python-frontmatter library loaded. Needed to read the YAML frontmatter from the files for the Draft command.

If you do try it out let me know if there are any changes you'd like or additions.

Edit: Just realised I will need to retake all of those screenshots.

On 6/12/2023 at 9:21 AM, vitor said:

I’ve very up to supporting Codeberg, but in its current state it’s not really viable.

I have set my Codeberg repos to mirror to Github. So there will be Github updates within a few minutes of me posting it to Codeberg. The only thing I need to do is to post a Release. 

2 minutes ago, Andrew said:

Having said that, there is absolutely nothing wrong in how you want to use Alfred, he's there to do what you need, and I appreciate your preference outlined here

Its not really a preference. Its just how I have been using it. 🙂

I was hoping to explain what the confusion was and expand on the use case that was leading to it. It is a bit of an edge case and it is easy to avoid.

That said, looking at the second screenshot I posted I think you will agree that there is a lot of room there for a new user (or someone with their own odd usage pattern) to assume that the Workflow isn't running.

As I mentioned, I have changed the Keyword and that solves all of the problems. I doubt that many people will run into a similar issue. 

Thanks

I am trying to build a python script that uses the frontmatter library to read some YAML data from files. The library is installed. It shows up in `pip list` and pip will also show the details of the library.

Name: python-frontmatter
Version: 1.0.0
Summary: Parse and manage posts with YAML (or other) frontmatter
Home-page: https://github.com/eyeseast/python-frontmatter
Author: Chris Amico
Author-email: eyeseast@gmail.com
License: MIT
Location: /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages
Requires: PyYAML
Required-by:

I tested the code in PyCharm as well before I ported it to Alfred and it ran correctly there.

When I drop the code into Alfred I get the following error. I am using the /usr/bin/python3 option

Code 1: Traceback (most recent call last):
File "/Users/Zac/Library/Caches/com.runningwithcrayons.Alfred/Workflow Scripts/B98FC667-F18E-4119-80F5-A521C67631EC", line 4, in <module>
    import frontmatter
ModuleNotFoundError: No module named 'frontmatter'

I moved the script to run externally and that works just fine. 

When I use `which python3` it shows the correct path. 

How is Alfred not finding the library if it is installed at the system path for Python?

I also do not have Homebrew python installed

20 minutes ago, Andrew said:

Add a Hotkey Trigger, or a Keyword Input (set to no arg), connected to your Script Filter. This essentially bootstraps Alfred into a different mode specifically for your workflow (you'll notice the Script Filter (or workflow icon) on the right hand side of the window instead of the Alfred icon.

I actually had it set like that initially but it was suggested to me that this was not an effective way to build the workflow.

21 minutes ago, Andrew said:

Does this help clarify a few things?

I did change the keyword to something more distinct but I think that I am going to go back and add a keyword to initialise the Workflow as I liked the way that it seemed to present the data when I was using it. 

23 minutes ago, Andrew said:

Seeing other results is also absolutely necessary in this instance, as e.g. if you wanted to launch Color Picker in one instance, then 'col' has to give you that result too.

I totally understand that. 

As a user, what is I see happening is that Alfred is running my Workflow and feeding in results without telling me that it is running my Workflow. Since I still see other potential actions in the window it is slightly confusing. 

I suspect that this is why I had a Keyword Input to activate the Script Filter initially. 

I mentioned the Placeholder text earlier as it struck me that Alfred would at least present me with something to indicate that it was working on my Workflow.

The Workflow currently uses the keyword `obCol` which I will change as I don't want to stop over the keywords in the Screaming Obsidian Workflow. It appears to run much differently from my perspective

If I type `obC` it shows the Workflow as the only option. But I still need to hit return to run it or type the entire keyword. Once the Keyword is entered it runs and shows results. 

This is the exact same thing that is happening when I had the `col` keyword but the difference is that to the user they only see the data they expect to see. Nothing else.

I understand that there is an assumption that you can just keep typing and Alfred changes the results it shows but from a user perspective there is reinforced action of using the return key to activate things. If a user doesn't normally type out all of the keyword but just types enough for it to show and then selects it with a return to "activate it" then they will assume that this is how the app works. The prominent appearance of the return symbol in the result list will serve to reinforce that. 

So from one use case, having the Workflow run without having to select it and hit return is not standard. 

I hope that makes sense. 

So in this particular instance, how does the user tell the difference between it working and it just disappearing?

Update: I went back and ran it again and neither the Placeholder Title or Subtext shows when this runs.  When I type in a space the rest of the results clear out but I still don't have any feedback that the Workflow did what it was supposed to. 

Is there something I can do to force Alfred to clear the results and display the Placeholders? 

20 hours ago, vitor said:

Seems like the workflow activated, rather. Aren’t those the options at the bottom?

It wasn't ever selected though. I type the 'l' character and the 'Create...' Workflow disappears. 

I recently started using an IRC client on my Mac. I guess I didn't feel 'old school' enough using the terminal.

The app's name is Colloquy and it has started to interfere with one of my Alfred Workflows when I try to activate it.

So if I activate Alfred and type `co` it will show both options (see first image). The keyword for the Workflow is `col`. When I type `col` the entry for the Workflow disappears (second image). 

Aside from renaming the Workflow, is there a way to stop this from happening? Or is it a bug?

Hi!

On 5/24/2023 at 3:32 AM, asclepius said:

This seems like a great idea and workflow however., I cannot seem get this to work at all

If you look at the Snippet Trigger you will see that it needs a keyword to work. My keyword is URL.

So I type \\<keyword> and it then gets the URL from my browser

Depends on your browser. If you are creating the URL you can add a target="new" attribute to the url and see if that works.

Where is the URL being generated?

2 hours ago, vitor said:

but unfortunately it does not support ETags

What are ETags?

2 hours ago, vitor said:

Such platforms usually have a repo (or something else public) where features can be requested/discussed. Do you know if Codeberg has it and where it’s located?

I believe that it is here

https://codeberg.org/Codeberg/Community/issues

Release posted

4 hours ago, vitor said:

That looks OK. Could you make a release?

It would just be a test but I can 🙂

This is my first repo there

https://codeberg.org/lolbat/Victor

It does have an RSS feed. I was going to use it for all future code and leave the existing code where it is. I don't want to complicate any existing posts

Probably just a question for @vitor but would we be able to use Codeberg to host Workflows as well as Github?

I have a new version of this but I am going to start a new topic as the name of the Workflow has changed

I now have it using the frontmost app. I just need to do some tests to make sure that the names returned from the Automation Task match the values I am branching from.

8 hours ago, vitor said:

Instead of grabbing the default browser, I would recommend grabbing the frontmost app and then acting accordingly

I actually thought that it might be more likely that someone would have multiple browsers open and so in that case using the frontmost app makes more sense