pupcan now collect some packaging paramenters -- icon-path, license-path, nice-name, and launch-module -- from the project's wheel metadata (warning: it's very very hackish!). (#123)- The tool used to build Linux AppImages is no longer hardcoded to a specific version/URL.
It defaults to https://github.com/AppImage/AppImageKit/releases/download/13/appimagetool-x86_64.AppImage but can be overridden with the
PUP_AIT_URLenvironment variable. (#208) - Linux AppImage filenames now include the packaged application's version. (#209)
- Both macOS and Windows packaging now accept PNG files for icons. The native formats, respectively, ICNS and ICO, are still supported. (#211)
- The packaged Python version can now be set with the
--python-versionCLI flag (if thePUP_PBS_URLenvironment variable is set, it takes precedence, however). (#214)
- HTTP downloads now follow redirects. (#225)
- The wheel generated during the metadata colletion stage is now kept under the build directory and used by the installation stage. (#30)
- Updated direct
pupdependencies. (#220)
- Added support for Python 3.9 and 3.10, linking to the most recent Python Build Standalone release that works effortlessly. Also updated the Python Build Standalone releases for Python 3.8. (#202)
- Fixed Linux AppDir packaging under Docker containers. (#201)
- Packaged applications are now launched with the
-IPython CLI flag. This isolates them from the users' site packages directory and environment. Can be overridden with the new--launch-pyflagpackaging option. (#195)
- Bundle Linux AppImage template with pup, otherwise packaging fails. (#190)
- Preliminary support for x86-64 Linux AppImage packaging:
requires
--icon-pathwith a PNG image and, for now, sets the category to "Education" in the bundled.desktopfile. (#150)
- Packaging directly from PyPI now works.
Up until now,
the code wrongly took the source project to be
a
pip-installable project on the filesystem. (#137) - The macOS binary launcher introduced in release 1.0.0a11 failed on Apple Silicon systems. Now fixed. (#185)
- With the new binary launcher in release 1.0.0a11, macOS packaged applications are no longer backwards compatible: applications packaged in 10.15 do not launch on 10.14, for example. This is an attempt at fixing that. (#177)
The Windows MSI installer UI now includes auto-generated bitmaps displaying the packaged application icon. (#103)
The Windows MSI installation process can now launch the installed program when done. Limitation: only works if a license is included to be displayed and accepted, which serves the near-term use case for Mu Editor. (#145)
Documented how to attain Windows MSI per-machine installs. (#151)
macOS launcher is now a native executable, compiled at packaging time. This leads to a cleaner user experience when macOS asks if the application should be allowed to access files or other HW devices: with the previous bash-script based solution the user would be asked about
/bin/bash. Users are now asked about the proper application name.Additionally, the main menu should now display the correct application name, instead of
pythonX.Yas before. (#153)
- Windows MSI installation now adds a single top-level entry to the Start Menu, whereas before a directory containing the program launching entry was created: less is more. (#147)
- Documented Windows MSI limitations regarding non-final PEP-440 versions,
like
1.1.0b2or1.1.0rc1, and the implications it has on the end-user software upgrade process. (#155) - Updated the default Python Standalone 3.8 bundle from 3.8.5 to 3.8.11. (#169)
- Fixed macOS signing of bundled files to support Mu Editor 1.0.0b5 that ships Python wheels within a ZIP file. The signing process now recurses into both wheel and ZIP files. (#156)
- macOS sign and notarize code cleanup: no need to reinvent
shutil.which. (#141)
- On macOS,
pupnow signs shared libraries bundled in wheel files that the application itself bundles, as is the case of the Mu Editor -- this is required for notarization. (#140)
- An
entitlements.plistfile, required for the macOS signing process, is now bundled. Previous versions unintentionally failed to do that, preventing the successful signature and subsequent notarization of packaged applications on macOS. (#138)
- The Python Build Standalone package to be used can now be overridden via the
PUP_PBS_URLenvironment variable -- for now this is a stop gap capability to support packaging 32-bit Windows applications using, for example, https://github.com/indygreg/python-build-standalone/releases/download/20200822/cpython-3.7.9-i686-pc-windows-msvc-shared-pgo-20200823T0159.tar.zst. (#125)
- macOS packaged applications failed running
tkinterandturtlecode when such code was running under a virtual environment -- much like what Mu Editor does. Now fixed. (#122) - macOS DMG creation failed when
pupwas installed into a virtual environment but invoked without activating it. Now fixed. (#125)
- Changed the packaging sequence. (#128)
- PyPI distributed
pupfailed miserably because it did not include all of its own bundled templates -- now fixed. (#118)
- The new
--nice-namepackaging option overrides the default application name, extracted from the distribution's metadata, with a more user-friendly name. (#41) - The packaging process can now use custom icons via the
--icon-pathoption. Custom icons are used on macOS application bundles and DMG files, as well as on the Windows Start Menu and Program and Features entries. (#90) - An optional license agreement can now be provided with the
--license-pathoption. It must be an ASCII-encoded text file that will be displayed to end-users, requiring their agreement before the installation can proceed. (#91) - The Windows packaging process
can now sign the packaged binary
.exe.,.dll, and.pydfiles, as well as the final MSI file. (#97) - Updated the documentation and added a few entries to the "thanks" list. (#108)
- Fixed a bug that prevented packaging non-signed Windows applications. (#101)
- Fixed a bug that prevented macOS signing and notarization with the
--nice-nameoption. (#111)
- Updated versions of direct dependencies. (#109)
- Minmally usable macOS DMG files are now produced: no icons, no customization yet. (#66)
- Minimally usable Windows MSI files are now produced. They are user-installable, do not include a GUI, and add a single Start Menu entry, for now, with no custom icon. Its implementation depends on the WiX toolset, which is automatically downloaded and cached for subsequent usage. (#82)
- Updated the documentation to reflect the new capabilities. (#94)
- Running the Windows
.vbslauncher from a directory other than the one containing it, in a CLI, no longer fails. (#48)
- Updated PyPI classifiers: no longer planning but in alpha. For now we only support Python 3.7 and 3.8. (#81)
- Some third party direct dependency versions were updated. (#89)
- Fixed pup packaging so that the required cookiecutter templates are bundled. (#77)
- Resulting macOS application bundles are now signed and notarized. (#43)
- Distributable artifacts now smaller. Many unneeded files and directory removed during the packaging process. (#38)
- Subprocess output,
like
pip's, is now tracked and logged live. (#32)
- macOS application bundles with names containing spaces now launch. (#44)
- Renamed
pupto Pluggable Micro Packager. (#71) - Added minimal usage documentation. (#70)
- Updated development documentation. (#68)
- Simpler log format when output is a TTY: no timestamps and no logger name. (#52)
- Changed the default logging level to INFO. (#58)
- Now logs exception tracebacks at CRITICAL level. (#51)
- First release that actually does something. Minimal packaging to a relocatable directory works and includes a GUI clickable "thing" to launch the application -- on macOS and Windows, for Python 3.7 and 3.8 (#34).
pupexists as a CLI tool, ispip-installable, and returns 42.