crabnebula-dev / cargo-packager Goto Github PK

Let's support our friends over at openbb and build an example for pywry

OpenBB-finance/pywry#111

When using Wix to create an installer, the installer will put the executable into Program Files, but the executable doesn't have access to Program Files, unless the user always runs the program as an admin. Thus, creating a log file just fails. Also, when uninstalling, the log file is left behind.

How could I specify to install to a location which is not "protected" (preferred), or give the program elevated privileges? Sorry, I'm really new to making installers.

Hi,
I've run into a case where my electron application crashes due to invalid signing of some files on mac. This mainly applies to some native binaries (dylib and executables) inside the bundled framework directories. This also breaks the notarization process.

1. "deep" codesigning will break complex applications in the hardened runtime

As described by Apple it is highly discouraged to use the --deep codesign flag. I therefore suggest manually signing all relevant files (which should be mostly Mach-O files).

2. Timestamps are missing

When submitting an application for notarization, Apple requires a timestamp metadata to indicate when the file was signed.
--timestamp should be used on every codesign process.

Hi,
I am currently trying to package a node application via cargo-packager's js bindings.
When I execute the packager binary, I get the following error.

➜  nodetest packager
node:internal/modules/cjs/loader:1147
  throw err;
  ^

Error: Cannot find module './build'
Require stack:
- /tmp/nodetest/node_modules/@crabnebula/packager/packager.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1144:15)
    at Module._load (node:internal/modules/cjs/loader:985:27)
    at Module.require (node:internal/modules/cjs/loader:1235:19)
    at require (node:internal/modules/helpers:176:18)
    at Object.<anonymous> (/tmp/nodetest/node_modules/@crabnebula/packager/packager.js:3:13)
    at Module._compile (node:internal/modules/cjs/loader:1376:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
    at Module.load (node:internal/modules/cjs/loader:1207:32)
    at Module._load (node:internal/modules/cjs/loader:1023:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:135:12) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [ '/tmp/nodetest/node_modules/@crabnebula/packager/packager.js' ]
}

Node.js v20.10.0

it seems that the autogenerated build folder in bindings/packager/nodejs/build does not get published with the npm package.

I then tried to copy the generated build folder into my node_modules folder to check if I can get the project working with that.
The error goes away, but I now run into an error that packager wants to look for a Cargo.toml which is quite unexpected when packaging a node project.

ERROR Failed to read cargo metadata: `cargo metadata` exited with an error: error: could not find `Cargo.toml` in `/tmp/nodetest` or any parent directory

If I understand the binding project correct, it is meant to be used for packaging standalone node projects which do not contain any rust and therefore no Cargo.toml, right?

Cargo Updater expects a .AppImage.tar.gz file with the following content when beeing executed from the context of an Linux AppImage:

// ├── [AppName]_[version]_amd64.AppImage.tar.gz    # GZ generated by cargo-packager
// │   └──[AppName]_[version]_amd64.AppImage        # Application AppImage
// └── ...

See here.
Cargo Packager does not emit these files.

In two places

kuchiki is unmaintained

The kuchiki repo was marked as archived in this commit.

Possible Alternatives

Possible alternatives may include:

• kuchikiki
• html5ever
• xml-rs

See advisory page for additional details.

In order to build and sign windows installers on linux CI need to override signtools call to use other tools. Please provide a way how to override executables(with command lines) for signing calls.
Idealy to have a callback called to do the job for each executable, it allows to tag something into the signature as well, otherwise take the executable path/parameters from packager config.

I don't really know if this is wanted.

When we invoke the packager using any of the NPM commands,

# pnpm
pnpm packager --release
# yarn
yarn packager --release
# npm
npx packager --release

It produces the error

ERROR Failed to read cargo metadata: cargo metadata exited with an error: error: could not find Cargo.toml in /home/namang/Desktop/Temp/tauri-app or any parent directory

Even though Packager.toml or package.json file do have the Cargo Packager configurations.

How to reproduce :

1. Create a Tauri app using pnpm create tauri-app any of NPM commands.
2. Use pnpm install
3. Add cargo-packager using pnpm add -D @crabnebula/packager
4. Add Packager configuration in the Packager.toml file.
5. Run pnpm packager --release

Expected Behaviour:
Packager Configuration from Packager.toml or package.json should be detected and used instead of asking for Cargo.toml file again and again.

Is there plan to make a loader ressource path or somethings? It would be usefull.

Add support for a Package.toml file so that package related info has it's own place (and can be specified for non Cargo projects too)

This should also add a --config, -c flag to specify the config file.

The preferred order of resolution should be --config > Pacakger.toml > Cargo.toml and configurations should not be merged

I think #117 broke deb somehow.

When i launch my app, i get this error message:

$ fan-control
bash: /usr/bin/fan-control: Permission non accordée

(permission denied)

There is no auto completion.

$ sudo /usr/bin/fan-control
sudo: /usr/bin/fan-control : commande introuvable

$ ls /usr/bin/fan-control
/usr/bin/fan-control

(command not found)

I tested to revert the commit, and it worked again

@naman-crabnebula

Cargo-packager relies on ureq for its HTTPS requests and enables native-tls on all arm builds.
Since cargo-packager constructs the ureq client without specifying an explicit tls implementation and ureq does not automatically enable native-tls capabilities just because it was enabled as a feature flag, any HTTPS requests will result in an error generated by the NOOP fallback implementation that is used by default when rustls is disabled.

This is a problem when trying to package an nsis on windows arm or a dmg on m1 macos for example.

ref: tauri-apps/tauri#7074

Since our current implementation is ported from tauri-bundler, we are subject to this issue as well.

_RAD-5

Offering a NPM package for this project would be huge for JavaScript developers that do not want to install Rust and manage dependencies with Cargo. For instance Electron users using electron-builder or electron-packager could simply install our NPM package and change their build scripts to use it. We could even accept the same configuration objects to simplify the migration process.

This can be achieved with napi-rs.

_RAD-54

I'm trying to build packages on windows and macOS, when I ran the command cargo packager on project directory

the following error is shown on terminal

ERROR No such file or directory. (os error 2)`

When I used the --verbose flag, the error message is not better in terms of information

DEBUG cargo_packager::shell: Running Command `"rustc" "--print" "cfg"`
DEBUG cargo_packager::shell: debug_assertions
DEBUG cargo_packager::shell: panic="unwind"
DEBUG cargo_packager::shell: target_arch="x86_64"
DEBUG cargo_packager::shell: target_endian="little"
DEBUG cargo_packager::shell: target_env="msvc"
DEBUG cargo_packager::shell: target_family="windows"
DEBUG cargo_packager::shell: target_feature="fxsr"
DEBUG cargo_packager::shell: target_feature="sse"
DEBUG cargo_packager::shell: target_feature="sse2"
DEBUG cargo_packager::shell: target_has_atomic="16"
DEBUG cargo_packager::shell: target_has_atomic="32"
DEBUG cargo_packager::shell: target_has_atomic="64"
DEBUG cargo_packager::shell: target_has_atomic="8"
DEBUG cargo_packager::shell: target_has_atomic="ptr"
DEBUG cargo_packager::shell: target_os="windows"
DEBUG cargo_packager::shell: target_pointer_width="64"
DEBUG cargo_packager::shell: target_vendor="pc"
DEBUG cargo_packager::shell: windows
ERROR cargo_packager::cli: No such file or directory. (os error 2)

I'm using packager.json with the following content:

{
    "name": "telescope",
    "description": "description",
    "longDescription": null,
    "enabled": true,
    "productName": "Telescope",
    "version": "0.0.1",
    "binaries": [
      {
        "path": "telescope",
        "main": true
      }
    ],
    "identifier": "org.rafaga.telescope",
    "beforePackagingCommand": null,
    "beforeEachPackageCommand": null,
    "logLevel": "info",
    "formats": null,
    "targetTriple": null,
    "homepage": "http://github.com/",
    "icons": ["../assets/icon01-256.png","../assets/icon01-1024.png"],
    "authors": [
      "Rafael Amador Galván"
    ],
    "publisher": null,
    "licenseFile": "../LICENSE.md",
    "copyright": null,
    "category": "Utility",
    "fileAssociations": null,
    "resources": [
      {
        "src": "assets/icon01-*.png",
        "target": "assets/icon01.*.png"
      },
      "Lorem ipsum"
    ],
    "externalBinaries": null,
    "windows": {
      "tsp": true,
      "allowDowngrades": true
    },
    "macos": {
      "frameworks": null,
      "entitlements": null
    },
    "deb": null,
    "appimage": null,
    "pacman": null,
    "wix": null,
    "nsis": {
      "compression": "lzma",
      "headerImage": null,
      "installerIcon": null,
      "installMode": "currentUser",
      "languages": [
        "English",
        "Spanish"
      ],
      "displayLanguageSelector": true,
      "appdataPaths": ["$LOCALAPPDATA/$PRODUCTNAME"]
    },
    "dmg":{
      "background": null
    }
  }

There is any way to get more helpful error messages?

Hi everyone, I have an electron app and want to try this packager. Please add some README how can I attach it to the existing project? Now it is based on https://www.npmjs.com/package/@electron-forge/maker-squirrel, and I would like to change it for something better, thanks

It will be cool if we could write this:

icons = ["ressource/app_icon/*"]

because i have currently 9 icons to bundle.

Also, why not renaming icons to app-icon or app-icons?
Personally prefer app-icon

Cargo.toml:

[package.metadata.packager]
before-packaging-command = "cargo build --release"
identifier = "com.acme.foo"
product-name = "Foo"
formats = ["nsis"]
resources = [
    { src = "assets/icons/*", target = "assets/icons" },
    { src = "assets/nsis/*", target = "assets/nsis" },
]
icons = [
    "assets/icons/32x32.png",
    "assets/icons/128x128.png",
    "assets/icons/icon.ico",
]

[package.metadata.package.nsis]
installer_icon = "assets/icons/icon.ico"
header_image = "assets/nsis/header.bmp"
sidebar_image = "assets/nsis/sidebar.bmp"
install_mode = "CurrentUser"
appdata_paths = ["$LOCALAPPDATA/$PUBLISHER/$PRODUCTNAME"]

The images: nsis.zip

Installer screenshots:

generational-arena is unmaintained

The generational-arena crate's repository has been archived and is no longer maintained.

Alternatives

• slotmap

See advisory page for additional details.

safemem is unmaintained

The latest crates.io release was in 2019. The repository has been archived by the author.

See advisory page for additional details.