I have a Python-package that calls Inkscape as part of a conversion process. I have it installed, but through Flatpak. This means that calling inkscape does not work in the terminal, but rather flatpak run org.inkscape.Inkscape. I need the package to be able to call it as inkscape.

What is the best way to go about this?

    • cyberwolfie@lemmy.mlOP
      link
      fedilink
      arrow-up
      10
      ·
      11 months ago

      Yeah, I tried this, and it works from my session, but I still got the same error from trying to run the program. I figured it was because it is called outside the bash session so the run commands have not been run, but is that perhaps not true?

      • ForynGilnith@lemmy.world
        link
        fedilink
        English
        arrow-up
        40
        ·
        edit-2
        11 months ago

        If that’s the case, it’s a bit of an ugly hack but you could make a wrapper script placed in /usr/local/bin/inkscape like this:

        #!/bin/bash
        
        flatpack run org.inkscape.Inkscape ${*}
        

        (the ${*} will pass along all the arguments that the wrapper script was called with)

        • cyberwolfie@lemmy.mlOP
          link
          fedilink
          arrow-up
          13
          ·
          11 months ago

          Thanks! I was trying to implement this, and was trying to figure out how to pass all the arguments! This worked for me! I got some other errors, but they don’t seem related to this, so now to find out what they are all about 😅

        • Josh
          link
          fedilink
          arrow-up
          1
          ·
          11 months ago

          Saving this for later, that’s genius.

  • Ananace@lemmy.ananace.dev
    link
    fedilink
    arrow-up
    37
    arrow-down
    2
    ·
    edit-2
    11 months ago

    Flatpak already creates executable wrappers for all applications as part of regular installs, though they’re by default named as the full package name.

    For when inkscape has been installed into the system-wide Flatpak installation, you could simply symlink it like; ln -s /var/lib/flatpak/exports/bin/org.inkscape.Inkscape /usr/local/bin/inkscape

    For the user-local installation, the exported runnable is in ~/.local/share/flatpak/exports/bin instead.

    • rotopenguin@infosec.pub
      link
      fedilink
      English
      arrow-up
      16
      ·
      11 months ago

      I handle it more like ln -s /var/lib/flatpak/exports/bin/org.inkscape.Inkscape ~/.local/bin/inkscape

      .local/bin is a directory that you may have to make, but your shell’s startup scripts should automatically add it to the PATH after that.

      • Ananace@lemmy.ananace.dev
        link
        fedilink
        arrow-up
        1
        ·
        11 months ago

        I personally use ~/.bin for my own symlinks, though I also use the user-specific installation instead of the system-wide one.
        I wouldn’t guarantee that any automation handles ~/.local/bin or ~/.bin either, that would depend entirely on the distribution. In my case I’ve added both to PATH manually.

  • Tzeentch@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    5
    ·
    11 months ago

    Two utilities that may be handy for you here:

    Pakrat: Automates and simplifies the process of creating alliases for flatpaks, good if you just need to make a few programs be simplified

    Fuzzpak: Lets you do fuzzy searches for flatpaks(as in you just write fuzzpak inkscape and it auto looks for something with inkscape in the flatpak folder and launches it), good for when you want to simplify launching flatpaks in general without doing the process of configuring stuff manually

  • smileyhead@discuss.tchncs.de
    link
    fedilink
    arrow-up
    4
    ·
    11 months ago

    You can do an alias for the shell you use or make a symlink to /usr/local/bin/ for the entire system.

    There are importany reasons why this is not the default, but you can do it as long as you are away you have done it. Like when programs installed via package manager and flatpak starts conflicting, you’ll know why.

  • adONis@lemmy.world
    link
    fedilink
    arrow-up
    4
    ·
    11 months ago

    Why don’t you check for both and use the one that’s available, otherwise print an error. Additionally you could read an env INKSCAPE_BIN and also include that in your checks.

    So one could for example do INKSCAPE_BIN='distrobox enter arch -- inkscape' python main.py

    • cyberwolfie@lemmy.mlOP
      link
      fedilink
      arrow-up
      2
      ·
      11 months ago

      It is not my package, but I could of course go ahead and change the source code directly to handle this. But I’d prefer a solution that would persist through updates.

    • OsrsNeedsF2P@lemmy.ml
      link
      fedilink
      arrow-up
      15
      arrow-down
      1
      ·
      11 months ago

      Yup, pack it up folks. We spent years working to solve containerized applications with a granular permission system, but we can’t figure out how to make an executable run a command. It was a good run, but it’s over now.

      • db2@lemmy.world
        link
        fedilink
        arrow-up
        1
        arrow-down
        1
        ·
        11 months ago

        Finally someone got the point instead of just downvoting. 🤣