Jump to content

wolph

Member
  • Posts

    68
  • Joined

  • Last visited

  • Days Won

    3

wolph last won the day on February 12 2020

wolph had the most liked content!

Recent Profile Visitors

1,131 profile views

wolph's Achievements

Member

Member (4/5)

8

Reputation

  1. That's not entirely true though. Right now it has to run both zsh and python instead of just python. Perhaps there is a different way of running it that I'm not aware of, but right now I don't see any way around running both of them. The external script option does not work because that does not support argv for some reason. Good point, to check I've done a little benchmark but I'm not noticing any meaningful difference here: $ for i in /usr/bin/python3 /usr/local/bin/python[0-9].[0-9]{,[0-9]}; do time $i -c 'import sys;print(sys.version)'; done 3.8.9 (default, Oct 26 2021, 07:25:54) [Clang 13.0.0 (clang-1300.0.29.30)] $i -c 'import sys;print(sys.version)' 0.03s user 0.01s system 92% cpu 0.038 total 2.7.17 (default, Oct 24 2019, 12:57:47) [GCC 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.8)] $i -c 'import sys;print(sys.version)' 0.01s user 0.01s system 90% cpu 0.030 total 3.7.13 (default, Mar 16 2022, 20:46:34) [Clang 13.0.0 (clang-1300.0.29.30)] $i -c 'import sys;print(sys.version)' 0.02s user 0.01s system 89% cpu 0.035 total 3.8.13 (default, Mar 16 2022, 20:38:02) [Clang 13.0.0 (clang-1300.0.29.30)] $i -c 'import sys;print(sys.version)' 0.02s user 0.01s system 90% cpu 0.035 total 3.9.12 (main, Mar 26 2022, 15:52:10) [Clang 13.0.0 (clang-1300.0.29.30)] $i -c 'import sys;print(sys.version)' 0.03s user 0.01s system 91% cpu 0.037 total 3.10.4 (main, Apr 26 2022, 19:43:24) [Clang 13.0.0 (clang-1300.0.29.30)] $i -c 'import sys;print(sys.version)' 0.02s user 0.01s system 91% cpu 0.033 total Oh wow... I wasn't aware of that. I stand corrected. In that case I think I'll just switch over to /usr/local/bin/python. If the user is required to install something anyway, it might be better to go for this. With regards to languages in the dropdown, it would certainly be nice of alfred would include more options. As can be seen in the benchmark above, I've got half a dozen python versions available and the dropdown doesn't show any of them. Having /usr/local/bin/python3 or /usr/bin/python3 at the very least would be an improvement.
  2. @vitorWhile those methods do work, on my system it appears to be significantly slower than the old Python integration (at least for the first run). I don't understand why `/usr/bin/python3` is not included as an option though. That's been available for several OS X versions already.
  3. I've implemented a version of it but I have to be careful not to break anything else. The syntax is "... to/from/diff/difference/change ..." and "... percentage of ..."
  4. Percentages were already somewhat supported but not in the way you're currently using them. Currently they're only part of ratios (i.e. parts per million) I've created a new version that supports pretty much all of this but it ignores the $ sign since there's no currency support yet.
  5. A (temporary) solution could be to use the unit converter I wrote: http://www.alfredforum.com/topic/5256-advanced-calculator-with-fast-off-line-unit-converter/ It's a lot faster and functions without an internet connection and it supports Alfred 2 without a problem. I should note that it probably supports less features so it's a small trade-off
  6. Well, it's just one possible option and not necessarily we should include. But I mean the other way around. This could be a shortcut to definining Alfred scriptfilters from the Python code itself. Instead of having to modify the plist yourself by adding a scriptfilter through Alfred you could have it automatically add a scriptfilter to the plist file using this decorator.
  7. That's a very good point. I think you are right, that is most likely the most convenient option here. Fully generating the files might not be that useful but some part could be. To make the creation of new packages easy it would be very nice if developers could do something like: @alfred.scriptfilter(keyword='spam') def some_function(query): pass That would automatically link that function to a scriptfilter using the specified keyword. Once it's generated there's no real need anymore so everything can be edited by Alfred after that but it can make the link between Alfred and the Python scripts easier
  8. That's indeed interesting information, thanks I suppose that would have to be included somewhere as well but I'm not sure what would be the best location. I don't think the entry_points would be a great fit. Personally I would recommend the usage of MANIFEST.in alone and simply ignore package_data. They largely overlap in functionality and I would argue that the MANIFEST.in system is easier to interpret as it doesn't offer any mapping/rewrite options. As for a better tutorial, chapter 15 of my book covers the usage of MANIFEST.in but I'm not sure if it's that much clearer... I'll send you the paragraph soon so you can judge for yourself Looks like a very nice starting point Ideally Alfred would support the entry points natively which would even make it possible to do a pip install -e workflow for development purposes. That would break backward compatibility however so I don't think that should be the first or only option. What I would like to propose is a setuptools build command which generates the entire workflow including the Alfred XML from the setup.py file. To ease development I think it should also contain a alfred_install or alfred_develop command to symlink the package so Alfred sees the workflow straight away. The added benefit of the setuptools entry points approach is that it would allow for a plugin manager to easily detect all Alfred plugins and show a list of available entry_points. That would allow for easy documentation as well since everything will be automatically generated The single strongest argument I can think of to go for a smart utility is consistency. A single silly mistake in a workflow can break everything which is especially annoying for inexperienced developers. Not having to worry about packaging, uploading and the writing of a plist file at least removes that part of the equation. Everything is open for discussion of course, as long as it makes it things easier for developers That could be interesting, and generally easier to write than setup.py files Ok, I'll edit the start post
  9. Noted and edited in the first post True... the documentation about extra files is lacking to say the least.The most useful documentation to me is the Python 2 documentation. For some reason this was removed with the Python 3 release unfortunately but the Python 2 docs are still available: https://docs.python.org/2/distutils/sourcedist.html#commands Given a bit of well documented boilerplate it might be enough for beginners. Alternatively, perhaps the cookiecutter package could help to make a simple create-a-workflow wizard: https://cookiecutter.readthedocs.org/en/latest/ I would personally vote for a documented standard, not something that is enforced in any way but simply an easy starting point for beginners with enough documentation to get a workflow up and running without too much effort. Assuming we create a cookiecutter template I think it would be easy enough.Alternatively, similar to how the django-admin command makes it possible to create a project using "django-admin startproject test" a "alfred create test" command could be created as well. Possibly even with an "alfred upload" or similar. Ideally this type of installation would be supported by Alfred internally but until that time we could have the bdist_alfred create a package that adds scriptfilters and such to a automatically generated plist file.So instead of having: setup( ... entry_points={ 'distutils.commands': [ 'upload_sphinx = sphinx_pypi_upload:UploadDoc', ], }, ) It could be something like: setup( ... entry_points={ 'alfred.scriptfilters': [ 'command = workflow_script:Command', 'optional_arg_command * = workflow_script:OptionalArgCommand', 'required_arg_command + = workflow_script:OptionalArgCommand', ], }, ) Note that all of this is purely theoretical at this point. But I do think it would make for an easier and more reusable system.
  10. Perhaps it wasn't meant as such but that's what I felt given your earlier reaction in this topic. It's probably just a matter of backgrounds, I have little experience in the Alfred world but a lot of experience with regular Python packages. With regular Python packages the workflow is generally as I suggested but that might not be the best fit for Alfred packages of course. It has given me an idea for an alternative solution however. Let's continue the discussion here: http://www.alfredforum.com/topic/8765-packaging-python-workflows-would-a-setuptools-command-be-useful/
  11. There are currently several methods for packaging workflows, all with advantages and disadvantages of course. For example: deanishe uses a script similar to: https://gist.github.com/deanishe/b16f018119ef3fe951af documents the export function within Alfred itself: https://alfredworkflow.readthedocs.org/en/latest/tutorial_2.html#sharing-your-workflow shawnrice appears to use a shell script: https://github.com/shawnrice/packal-updater/blob/master/alfred.bundler.sh Wolph (me) uses a Makefile: https://github.com/WoLpH/alfred-converter/blob/master/Makefile It seems to me that there is a better solution though. The setuptools package is widely used within the Python community to compile, build and deploy packages to the PyPI servers but it can do more. The Sphinx-PyPI-upload-2 package for example (https://github.com/WoLpH/sphinx-pypi-upload) makes it possible to upload Sphinx documentation to the PyPI servers which can be built using the commands from Sphinx itself. With that regard I propose a new solution for packaging Alfred workflows: Use entry_points to create a bdist_alfred command similar to bdist_wheel (https://wheel.readthedocs.org/) Create a upload_packal command similar to upload_sphinx (https://github.com/WoLpH/sphinx-pypi-upload/blob/master/setup.py#L32-L36) Create a standard for specifying Alfred entry points through the setup.py
  12. Well, compared to having a fulltime job, writing a book (https://www.packtpub.com/application-development/mastering-python), renovating a house and moving to that house (last friday) it should be a bit more quiet
  13. I'm still around. My apologies for not getting much up and running yet, my life has been a crazy rollercoaster ride the last year and a half... I hope/expect it to settle down a bit the coming months. Although I am about to become a father so not entirely sure about that either The only thing I didn't like was your condescending attitude. I realise that you have been a tremendous help for the Alfred community and I respect you for that but I if you're not open to discussing alternative solutions to common workflow problems... well, let's just say that limits my usefulness with your projects About this script, I'll resume working on it and will report back with the progress in about 2 weeks.
  14. That's currently not directly supported, but it's easy to work around it. Just type "6' in inch" followed by a tab, it will give you the size in inches straight away. After that you can simply add them I've added it to the todo: https://github.com/WoLpH/alfred-converter/issues/5
  15. Wow, works great Thanks Andrew! As for losing focus, while that's indeed an annoyance it might be preferable behaviour to the potential bugs after fixing it. Switching applications and purposefully defocussing Alfred might not be possible otherwise. At the very least that should have to be configurable.
×
×
  • Create New...