Easily manage wineprefix using environments
Read here how to translate Bottles in your language or how to help improve existing ones.
- Create bottles based on environments (a set of rule and dependencies for better software compatibility)
- Access to a customizable environment for all your experiments
- Run every executable (.exe/.msi) in your bottles, using the context menu in your file manager
- Integrated management and storage for executable file arguments
- Support for custom environment variables
- Simplified DLL overrides
- On-the-fly runner change for any Bottle
- Various optimizations for better gaming performance (esync, fsync, dxvk, cache, shader compiler, offload .. and much more.)
- Tweak different wine prefix settings, without leaving Bottles
- Automated dxvk installation
- Automatic installation and management of Wine and Proton runners
- System for checking runner updates for the bottle and automatic repair in case of breakage
- Integrated Dependencies installer with compatibility check based on a community-driver repository
- Detection of installed programs
- Integrated Task manager for wine processes
- Easy access to ProtonDB and WineHQ for support
- .. and much more that you can find by installing Bottles!
- Installer manager #55
- Configurations update system across Bottles versions
- Backup/Restore
- Importer (from other wineprefix manager)
- Optional sandboxed bottles
Disclaimer: This is a development version (alpha), you will find bugs, black holes and monsters under the bed. Be careful.
This is the official method by which we have chosen to distribute Bottles and it is the only one we currently officially support..
Download the latest Build, then:
chmod +x Bottles-commit-x86_64.AppImage
./Bottles-commit-x86_64.AppImage
And you're done!
These packages are maitained by our community but not officialy supported.
Distro | Package Name/Link | Maintainer |
---|---|---|
Arch Linux | bottles-git (AUR) |
Talebian12 |
Arch Linux | bottles (AUR) |
ragouel |
Tumbleweed | bottles |
WhiXard |
Fedora 33 | bottles |
WhiXard |
Void linux | bottles |
andry-dev |
We are happy to see packaged Bottles but we ask you to respect some small rules:
- The package must be
bottles
, in other distributions it is possible to use suffixes (e.g.bottles-git
on Arch Linux for the git based package) while on others the RDNN format is required (e.g.com.usebottles.bottles
on elementary OS and Flathub repository). All other nomenclatures are discouraged. - In the current development phase, the version corresponds to the formula (
2.commit
, e.g. 2.a005f01), where possible use this formula throughout the development phase. For stable and 'stable development' release you can use the version in the VERSION file and its release. Please don't travel into the future with releases. It might confuse users. - Do not package external files and do not make changes to the code, no hard script. Obviously with the exception of files essential for packaging. Once the package is published, you can open a Pull Request to add it to the packages table above! Thanks ❤️!
Instead of use the Appimage you can choose to build your own Bottles from source.
- meson
- ninja
- python3
mkdir build
meson build && cd build
ninja -j$(nproc)
sudo ninja install
cd build
sudo ninja uninstall
Getting a KeyError after Bottles update.
It could be caused by a change in the bottle configuration (a know bug
in beta).
Try this fix. If still
doesn't work, check if your bottle configuration.json follow the sample.
Bottles was born in 2017 as a personal need. I needed a practical way to manage my wineprefixes. I hate the idea of using applications that install me a version of wine for each application and I decided to create this application, based on the concept of using one or more wine prefixes as a "container" for all my applications.
In 2020 thanks to Valve, we have access to Proton. An optimized version of Wine for gaming. Thanks also to other projects like DXVK/VKD3D/Esync/Fsync/Shader compiler and others, we can run a large set of video games designed for Windows, on Linux.
The idea of creating an environment-based wineprefix manager comes from the standardization of dependencies and parameters necessary to run a game. On the other hand, we have software (often not up to date) that require environments and configurations different from those used in gaming. Hence the idea of managing separate environments.
Because they are similar but different applications. I want to create environments that contain more applications and games and where the wine version can be updated.
I also want to be able to export my bottles allowing easy sharing, with or without applications. In POL/Lutris we have the concept of "with this version of wine and these changes it works". In Bottles the concept is "this is my wine bottle, I want to install this software".
The goal with this version is also to integrate with the system in the best possible way. Being able to decide in a few bottles to run an .exe/.msi file and have control over it without having to open Bottles for each operation.
Bottles is close to what wineprefix means, since v.2 it provides a simplified method to generate environment-based bottles and thanks to other tools it simplifies the management but nothing more.
On December 3, 2020 we announced our intentions to migrate to Appimage as the official format for Bottles distribution. Read more.
There is not. There will never be. Read here our reasons and how we want to revolutionize the way we install dependencies in Bottles.
Idk. Really. Keep an eye on the develop branch, sooner or later there will be an almost stable release.
Maybe in the future, not now. I will keep both branches updated for a long time.
Probably yes. I would like to allow the conversion of the old wine prefixes in v.2.
Unlike the previous versions, now the bottles are saved with JSON sheets containing all the instructions and settings, such as the version of wine/proton in use, the various active flags etc.