[ENHANCEMENT] Windows Support #3

celenity commented 2024年09月16日 08:35:06 +02:00

Filing this issue to keep track of Windows support:

Our config files work perfectly fine - the only problem is with our policies.json file. I need a way to package it so that we can provide Windows users with updates as needed.

I've looked into Chocolatey - but Chocolatey appears to require using Windows to build packages... I don't use Windows, so that's out for me.

If anyone has any ideas on how we can package & update this file for Windows similar to how we do for other platforms, please let me know!

Any ideas & help appreciated here. I definitely hate that we don't support Windows right now... needs to get sorted.

Filing this issue to keep track of Windows support: Our config files work perfectly fine - the only problem is with our `policies.json` file. I need a way to package it so that we can provide Windows users with updates as needed. I've looked into Chocolatey - but Chocolatey appears to require using Windows to build packages... I don't use Windows, so that's out for me. If anyone has any ideas on how we can package & update this file for Windows similar to how we do for other platforms, please let me know! Any ideas & help appreciated here. I definitely hate that we don't support Windows right now... needs to get sorted.

Gnu1 commented 2024年09月18日 17:17:29 +02:00

Hello.
Please remove install script of MacOs and Windows.
You created this Repo for user's privacy but MacOs and Windows don't respect to user privacy.

So you are destroying your try with Windows and MacOs supporting.

Note: If you think my text is strange so excuse me because my English is bad.

Hello. Please remove install script of MacOs and Windows. You created this Repo for user's privacy but MacOs and Windows don't respect to user privacy. So you are destroying your try with Windows and MacOs supporting. Note: If you think my text is strange so excuse me because my English is bad.

celenity commented 2024年09月18日 18:26:49 +02:00

Hi there @Gnu1,

Thank you so much for your support of this project.

To address your concerns:

Please remove install script of MacOs and Windows.
You created this Repo for user's privacy but MacOs and Windows don't respect to user privacy.

So you are destroying your try with Windows and MacOs supporting.

I agree that Windows isn't private, & I would never recommend using it (I don't use it myself...) - but does it not make sense for us to give those users a better option for browsing the web? Through giving them the ability to use Phoenix, we're at least mitigating the privacy damage done by using Windows, no? You could think of it as harm reduction.

I'll always support GNU/Linux distros & push people to use them where possible to be clear, but some people simply can't/won't use them, and there's not much we can do about that - it's out of scope here. So I feel that it makes sense to give these platforms support for Phoenix - especially since it isn't harming anything either. I don't think it's destroying the work we're doing...

Curious to hear your thoughts on this, and appreciate your feedback.

Hi there @Gnu1, Thank you so much for your support of this project. To address your concerns: > Please remove install script of MacOs and Windows. > You created this Repo for user's privacy but MacOs and Windows don't respect to user privacy. > So you are destroying your try with Windows and MacOs supporting. I agree that Windows isn't private, & I would never recommend using it (I don't use it myself...) - but does it not make sense for us to give those users a better option for browsing the web? Through giving them the ability to use Phoenix, we're at least mitigating the privacy damage done by using Windows, no? You could think of it as harm reduction. I'll always support GNU/Linux distros & push people to use them where possible to be clear, but some people simply can't/won't use them, and there's not much we can do about that - it's out of scope here. So I feel that it makes sense to give these platforms support for Phoenix - especially since it isn't harming anything either. I don't think it's `destroying` the work we're doing... Curious to hear your thoughts on this, and appreciate your feedback.

Gnu1 commented 2024年09月18日 20:42:43 +02:00

Firefox on Windows is very slow(because of Microsoft).
Apple products are very exclusive and closed.
It is of no use.

Thank you for your Repo.

I'll always support Linux distros & push people to use them where possible to be clear,

Do you mean Gnu OS distros? 🙃🙃

Firefox on Windows is very slow(because of Microsoft). Apple products are very exclusive and closed. It is of no use. Thank you for your Repo. >I'll always support **Linux** distros & push people to use them where possible to be clear, Do you mean Gnu OS distros? 🙃🙃

celenity commented 2024年09月18日 23:49:54 +02:00

Do your mean Gnu OS distros? 🙃🙃

just corrected - apologies :p

> Do your mean Gnu OS distros? 🙃🙃 just corrected - apologies :p

GW72 commented 2024年11月06日 12:12:32 +01:00

I'll always support GNU/Linux distros & push people to use them where possible to be clear, but some people simply can't/won't use them, and there's not much we can do about that - it's out of scope here. So I feel that it makes sense to give these platforms support for Phoenix - especially since it isn't harming anything either. I don't think it's destroying the work we're doing...

I've just added Phoenix (base) to Win11 (in VM and also PC) without problems, everything seems to be working fine.

Any effort to help MS sufferers, many of whom have NO CHOICE, either due to lack of specific software options only available for MS, or, due to a critical lack of knowledge/capabilities/skills to switch to some Linux distro, get even one millimeter more privacy, should be applauded and supported.

As time goes on, I need MS anything, less and less. But even with my minimal usage case, I am grateful to add protections to FF, on top of the long list of other (easily accessible) anti-privacy-intrusion mitigations one can find out there (and there are very many!). Win11 runs quite fine on an old tablet, with many services turned off, and many useful registry hacks (some custom, some from group policy menus).

> I'll always support GNU/Linux distros & push people to use them where possible to be clear, but some people simply can't/won't use them, and there's not much we can do about that - it's out of scope here. So I feel that it makes sense to give these platforms support for Phoenix - especially since it isn't harming anything either. I don't think it's `destroying` the work we're doing... I've just added Phoenix (base) to Win11 (in VM and also PC) without problems, everything seems to be working fine. Any effort to help MS sufferers, many of whom have NO CHOICE, either due to lack of specific software options only available for MS, or, due to a critical lack of knowledge/capabilities/skills to switch to some Linux distro, get even one millimeter more privacy, should be applauded and supported. As time goes on, I need MS anything, less and less. But even with my minimal usage case, I am grateful to add protections to FF, on top of the long list of other (easily accessible) anti-privacy-intrusion mitigations one can find out there (and there are very many!). Win11 runs quite fine on an old tablet, with many services turned off, and many useful registry hacks (some custom, some from group policy menus).

GW72 commented 2024年11月06日 14:52:25 +01:00

Our config files work perfectly fine - the only problem is with our policies.json file. I need a way to package it so that we can provide Windows users with updates as needed.

While I have no solution for automation, I could add the following. It literally takes less than 30 seconds, to download the policies.json file and drop it into the required directory.

While I understand from your side @celenity that it would definitely be more neat and tidy to have complete automation, considering the amount of work you have done in all these efforts, I don't find it too burdensome to take those 30 seconds, for all it gets me (or rather, gets me not). My 2 cents. And double that considering all this is FREE of charge.

One thing that would be useful in the meantime, is knowing which directory in the Phoenix-pages.zip to find either the base version, or, no-sync version, of the polices.json file. I don't mind using whatever version is available in the install instructions section, but I never know if what I save from there, is the most current version, same as what is available in the newest Phoenix-pages.zip.

> Our config files work perfectly fine - the only problem is with our `policies.json` file. I need a way to package it so that we can provide Windows users with updates as needed. While I have no solution for automation, I could add the following. It literally takes less than 30 seconds, to download the `policies.json` file and drop it into the required directory. While I understand from your side @celenity that it would definitely be more neat and tidy to have complete automation, considering the amount of work you have done in all these efforts, I don't find it too burdensome to take those 30 seconds, for all it gets me (or rather, gets me not). My 2 cents. And double that considering all this is FREE of charge. One thing that would be useful in the meantime, is knowing which directory in the Phoenix-pages.zip to find either the base version, or, no-sync version, of the `polices.json` file. I don't mind using whatever version is available in the install instructions section, but I never know if what I save from there, is the most current version, same as what is available in the newest Phoenix-pages.zip.

celenity commented 2024年11月07日 05:06:19 +01:00

Thanks for the feedback @GW72, I strongly agree with your points. As terrible as Windows is, we have to support it. I know countless friends and family members who won't/can't use anything else for one reason or another.

While I understand from your side @celenity that it would definitely be more neat and tidy to have complete automation, considering the amount of work you have done in all these efforts, I don't find it too burdensome to take those 30 seconds, for all it gets me (or rather, gets me not). My 2 cents. And double that considering all this is FREE of charge.

I think the problem ultimately is that we just can't expect most users to put in the time/work to manually update their policies. That's part of what I wanted to solve with Phoenix, I wanted to make this type of hardening more accessible to more people who may be less technical and don't want to bother with ex. user.js files, making overrides files, manually keeping up with updates, etc...

We do also block malicious/questionable add-ons that Mozilla misses via. the policies.json, so having users as up to date as soon as possible could prove important later down the line, as we could rapidly protect our users if something comes up.

That being said, you are 100% right. I shouldn't let perfect be the enemy of good. I don't see why we couldn't support Windows via manual installation for the time being until I figure out a way to automatically update policies (please let me know if you have any ideas!). Having it available manually is at least better than nothing.

One thing that would be useful in the meantime, is knowing which directory in the Phoenix-pages.zip to find either the base version, or, no-sync version, of the polices.json file. I don't mind using whatever version is available in the install instructions section, but I never know if what I save from there, is the most current version, same as what is available in the newest Phoenix-pages.zip.

The standard base policies.json file you'll want is located here (policies/Policies/policies.json).

The no-sync variant is located here (policies/No-Sync/policies.json).

I'll write up more specific instructions when I get a chance to add to the README. Glad you brought this up, not sure why I didn't already consider making it available manually.

Thanks for the feedback @GW72, I strongly agree with your points. As terrible as Windows is, we have to support it. I know countless friends and family members who won't/can't use anything else for one reason or another. > While I understand from your side @celenity that it would definitely be more neat and tidy to have complete automation, considering the amount of work you have done in all these efforts, I don't find it too burdensome to take those 30 seconds, for all it gets me (or rather, gets me not). My 2 cents. And double that considering all this is FREE of charge. I think the problem ultimately is that we just can't expect most users to put in the time/work to manually update their policies. That's part of what I wanted to solve with Phoenix, I wanted to make this type of hardening more accessible to more people who may be less technical and don't want to bother with ex. user.js files, making overrides files, manually keeping up with updates, etc... We do also block malicious/questionable add-ons that Mozilla misses via. the policies.json, so having users as up to date as soon as possible could prove important later down the line, as we could rapidly protect our users if something comes up. **That being said**, you are 100% right. I shouldn't let perfect be the enemy of good. I don't see why we couldn't support Windows via manual installation for the time being until I figure out a way to automatically update policies (please let me know if you have any ideas!). Having it available manually is at least better than nothing. > One thing that would be useful in the meantime, is knowing which directory in the Phoenix-pages.zip to find either the base version, or, no-sync version, of the polices.json file. I don't mind using whatever version is available in the install instructions section, but I never know if what I save from there, is the most current version, same as what is available in the newest Phoenix-pages.zip. The standard base `policies.json` file you'll want is located [here](https://codeberg.org/celenity/Phoenix/src/branch/pages/policies/Policies/policies.json) (`policies/Policies/policies.json`). The no-sync variant is located [here](https://codeberg.org/celenity/Phoenix/src/branch/pages/policies/No-Sync/policies.json) (`policies/No-Sync/policies.json`). I'll write up more specific instructions when I get a chance to add to the README. Glad you brought this up, not sure why I didn't already consider making it available manually.

GW72 commented 2024年11月07日 19:23:43 +01:00

Thanks for pointing out those policies.json directories. I'm now using the no-sync version without problems. I have yet to find any breakage on Linux with the hardened user.js set-up so will likely implement that soon as well.

I get it about the automation, and I would use that if it would be available. But I hate to think by this point in time, that it would be "too much" for someone to manage manual updates themselves. It's not rocket science. The routine is not demanding, but I suppose these days, that may be "relative".

Thanks for pointing out those `policies.json` directories. I'm now using the `no-sync` version without problems. I have yet to find any breakage on Linux with the hardened `user.js` set-up so will likely implement that soon as well. I get it about the automation, and I would use that if it would be available. But I hate to think by this point in time, that it would be "too much" for someone to manage manual updates themselves. It's not rocket science. The routine is not demanding, but I suppose these days, that may be "relative".

MahoganyPrime commented 2025年01月22日 20:32:53 +01:00

Thank you for your work and making time to care and support those who find themselves stuck on windows due to software, workflow, etc.

I did not see this mentioned thus why I am mentioning it.
Can't this automation be done via winget or at least be as easy as having users use winget to upgrade phoenix?

Thank you for your work and making time to care and support those who find themselves stuck on windows due to software, workflow, etc. I did not see this mentioned thus why I am mentioning it. Can't this automation be done via winget or at least be as easy as having users use winget to upgrade phoenix?

Gnu1 commented 2025年01月22日 20:42:44 +01:00

Can't this automation be done via winget or at least be as easy as having users use winget to upgrade phoenix?

Hi @MahoganyPrime
We need to a contributor not a way for updating.
If you can do this send a PR for updating on Windows

>Can't this automation be done via winget or at least be as easy as having users use winget to upgrade phoenix? Hi @MahoganyPrime We need to a contributor not a way for updating. If you can do this send a PR for updating on Windows

MahoganyPrime commented 2025年01月28日 06:47:32 +01:00

@Gnu1 wrote in #3 (comment):

Can't this automation be done via winget or at least be as easy as having users use winget to upgrade phoenix?

Hi @MahoganyPrime We need to a contributor not a way for updating. If you can do this send a PR for updating on Windows

I would love to help but this is not my area of expertise.

@Gnu1 wrote in https://codeberg.org/celenity/Phoenix/issues/3#issuecomment-2611794: > > Can't this automation be done via winget or at least be as easy as having users use winget to upgrade phoenix? > > Hi @MahoganyPrime We need to a contributor not a way for updating. If you can do this send a PR for updating on Windows I would love to help but this is not my area of expertise.

Gnu1 commented 2025年01月28日 06:55:13 +01:00

I would love to help but this is not my area of expertise.

Anyway thank you.

We need to a person that can work with Windows and make the packages with any way that uses Free software

> I would love to help but this is not my area of expertise. Anyway thank you. We need to a person that can work with Windows and make the packages with any way that uses Free software

AnonSky commented 2025年06月06日 13:56:47 +02:00

Hey team !

I've created an installer/updater in powershell if that's any use for you.

Regarding a winget package, we actually need an installer. The most simple way I've found is automating it with Github actions :

• https://github.com/actions/create-release
• https://www.advancedinstaller.com/automate-msi-building-using-github-actions.html

This would then allow winget to retrieve the MSI installer to setup Phoenix.
I think this way is the easiest because it's automatic so you don't even need to think about it.

For a Chocolatey package, you could use the automatic packaging feature (note that Linux support is as mentionned, limited)

• https://github.com/chocolatey-community/chocolatey-au
• https://docs.chocolatey.org/en-us/create/create-packages/#build-your-package
• https://docs.chocolatey.org/en-us/guides/non-windows/

I can def give it all a try but I'd need Celenity to set some things up for it to work properly.

Cheers

Hey team ! I've created an installer/updater in powershell if that's any use for you. Regarding a winget package, we actually need an installer. The most simple way I've found is automating it with Github actions : - https://github.com/actions/create-release - https://www.advancedinstaller.com/automate-msi-building-using-github-actions.html This would then allow winget to retrieve the MSI installer to setup Phoenix. I think this way is the easiest because it's automatic so you don't even need to think about it. For a Chocolatey package, you could use the automatic packaging feature (note that Linux support is as mentionned, limited) - https://github.com/chocolatey-community/chocolatey-au - https://docs.chocolatey.org/en-us/create/create-packages/#build-your-package - https://docs.chocolatey.org/en-us/guides/non-windows/ I can def give it all a try but I'd need Celenity to set some things up for it to work properly. Cheers

Gnu1 commented 2025年06月06日 16:24:23 +02:00

@AnonSky

Thank you but scripts are not usefull (Users can't use script for installing and updating Phoenix, If you created scripts for building and releasing packages and using yourself, it's can be good).

We should use a way for packaging phoenix for windows.

And we need to a person that builds and releases packages for windows.

Users should be able to update and install Phoenix only via one command.

For example:
winget install phoenix

See manually installation for knowing files pathes in the Windows filesystem.

https://codeberg.org/celenity/Phoenix#manual-installation

@AnonSky Thank you but scripts are not usefull (Users can't use script for installing and updating Phoenix, If you created scripts for building and releasing packages and using yourself, it's can be good). We should use a way for packaging phoenix for windows. And we need to a person that builds and releases packages for windows. Users should be able to update and install Phoenix only via one command. For example: `winget install phoenix` See manually installation for knowing files pathes in the Windows filesystem. https://codeberg.org/celenity/Phoenix#manual-installation

anxshi commented 2025年09月17日 20:49:46 +02:00

heyy,
i recently experimented a bit with the windows package manager scoop and today I tried setting up a manifest to easily install, uninstall and (probably) auto-update the phoenix suite for the user. It's experimental and more of a practice since I'm pretty new to coding (well, calling it coding is an overstatement - without the scoop documentation and the community i wouldn't be able to come up with this). hope, this helps in finding out how to distribute phoenix to windows users.
Thx for this really nice project, i'm heavily interested what the future brings :3

so the scoop manifest depends that firefox is installed via scoop, if not, it installs it. Then it downloads the files and copies them into their respective place in the scoop firefox directory. When uninstalling the phoenix suite, all previously copied files get removed, the package uninstalled, but firefox stays.

{
 "##": "experimental",
 "version": "2025年09月07日.1",
 "description": "Phoenix is a suite of configurations & advanced modifications for Mozilla Firefox, designed to put the user first - with a focus on privacy, security, freedom, & usability.",
 "homepage": "https://phoenix.celenity.dev/",
 "license": "GPL-3.0-or-later",
 "notes": "", 
 "depends": "extras/firefox",
 "url": "https://github.com/celenityy/Phoenix/archive/refs/tags/2025.09.07.1.zip",
 "extract_dir": "Phoenix-2025年09月07日.1\\windows",
 "post_install": [
 "Copy-Item -Path \"$dir\\phoenix.cfg\" -Destination \"$(appdir firefox)\\current\" -Force",
 "Copy-Item -Path \"$dir\\defaults\\pref\\phoenix.js\" -Destination \"$(appdir firefox)\\current\\defaults\\pref\" -Force",
 "Copy-Item -Path \"$dir\\distribution\\policies.json\" -Destination \"$(appdir firefox)\\current\\distribution\" -Force"
 ],
 "pre_uninstall": [
 "Remove-Item \"$(appdir firefox)\\current\\phoenix.cfg\" -Force",
 "Remove-Item \"$(appdir firefox)\\current\\defaults\\pref\\phoenix.js\" -Force",
 "Remove-Item \"$(appdir firefox)\\current\\distribution\\policies.json\" -Force"
 ],
 "checkver": {
 "github": "https://github.com/celenityy/Phoenix"
 },
 "autoupdate": {
 "url": "https://github.com/celenityy/Phoenix/archive/refs/tags/$version.zip",
 "extract_dir": "Phoenix-$version\\windows"
 }
}

heyy, i recently experimented a bit with the windows package manager [scoop](https://github.com/ScoopInstaller) and today I tried setting up a manifest to easily install, uninstall and (probably) auto-update the phoenix suite for the user. It's experimental and more of a practice since I'm pretty new to coding (well, calling it coding is an overstatement - without the scoop documentation and the community i wouldn't be able to come up with this). hope, this helps in finding out how to distribute phoenix to windows users. Thx for this really nice project, i'm heavily interested what the future brings :3 so the scoop [manifest](https://github.com/anxshi/various-infills/blob/4462b0a2445bfbf1254d77418d4f01a199b3f1e4/bucket/phoenix-suite.json) depends that firefox is installed via scoop, if not, it installs it. Then it downloads the files and copies them into their respective place in the scoop firefox directory. When uninstalling the phoenix suite, all previously copied files get removed, the package uninstalled, but firefox stays. ``` { "##": "experimental", "version": "2025年09月07日.1", "description": "Phoenix is a suite of configurations & advanced modifications for Mozilla Firefox, designed to put the user first - with a focus on privacy, security, freedom, & usability.", "homepage": "https://phoenix.celenity.dev/", "license": "GPL-3.0-or-later", "notes": "", "depends": "extras/firefox", "url": "https://github.com/celenityy/Phoenix/archive/refs/tags/2025.09.07.1.zip", "extract_dir": "Phoenix-2025年09月07日.1\\windows", "post_install": [ "Copy-Item -Path \"$dir\\phoenix.cfg\" -Destination \"$(appdir firefox)\\current\" -Force", "Copy-Item -Path \"$dir\\defaults\\pref\\phoenix.js\" -Destination \"$(appdir firefox)\\current\\defaults\\pref\" -Force", "Copy-Item -Path \"$dir\\distribution\\policies.json\" -Destination \"$(appdir firefox)\\current\\distribution\" -Force" ], "pre_uninstall": [ "Remove-Item \"$(appdir firefox)\\current\\phoenix.cfg\" -Force", "Remove-Item \"$(appdir firefox)\\current\\defaults\\pref\\phoenix.js\" -Force", "Remove-Item \"$(appdir firefox)\\current\\distribution\\policies.json\" -Force" ], "checkver": { "github": "https://github.com/celenityy/Phoenix" }, "autoupdate": { "url": "https://github.com/celenityy/Phoenix/archive/refs/tags/$version.zip", "extract_dir": "Phoenix-$version\\windows" } } ```

Gnu1 commented 2025年09月17日 21:10:01 +02:00

@anxshi

Thank you, but we should accept that windows is a bad rubbish.

This way (installing scoop, installing firefox and installing phoenix) is very long and hard

I think that we should forget windows.

@anxshi Thank you, but we should accept that windows is a bad rubbish. This way (installing scoop, installing firefox and installing phoenix) is very long and hard I think that we should forget windows.

anxshi commented 2025年09月17日 21:36:37 +02:00

windows is indeed rubbish, but installing firefox is necessary on every platform, or am i silly?
Long and hard is very opinionated - this is a similar process to installing phoenix through flatpak:

Flatpak	Scoop
Install Flatpak	Install Scoop
Add Remote	Add Bucket
Install Phoenix	Install Phoenix

windows is indeed rubbish, but installing firefox is necessary on every platform, or am i silly? Long and hard is very opinionated - this is a similar process to installing phoenix through flatpak: | Flatpak | Scoop | |---------|---------| | Install Flatpak | Install Scoop | | Add Remote | Add Bucket | | Install Phoenix | Install Phoenix |

Gnu1 commented 2025年09月17日 22:28:58 +02:00

@anxshi wrote in #3 (comment):

windows is indeed rubbish, but installing firefox is necessary on every platform, or am i silly? Long and hard is very opinionated - this is a similar process to installing phoenix through flatpak:

Exactly because of this I don't use flatpak.

BTW did you test it?

@anxshi wrote in https://codeberg.org/celenity/Phoenix/issues/3#issuecomment-7232710: > windows is indeed rubbish, but installing firefox is necessary on every platform, or am i silly? Long and hard is very opinionated - this is a similar process to installing phoenix through flatpak: Exactly because of this I don't use flatpak. BTW did you test it?

anxshi commented 2025年09月18日 02:11:42 +02:00

Exactly because of this I don't use flatpak.

Some do tho, for example people who use atomic distros

BTW did you test it?

yes, this experimental test seemed successful to me

> Exactly because of this I don't use flatpak. Some do tho, for example people who use atomic distros > BTW did you test it? yes, this experimental test seemed successful to me

celenity commented 2025年09月18日 16:59:36 +02:00

I'll take a look at this and do some testing when I have a chance - thank you both for your time and efforts! @anxshi @AnonSky Very much appreciated.

Based on a quick glance, a lot of what I'm seeing from Scoop mentions installation - @anxshi can Scoop also handle updates? I think that's probably the most important thing to solve here in terms of proper Windows support (though, obviously, having an easier way to install/manage Phoenix on Windows is still very welcome).

I'll take a look at this and do some testing when I have a chance - thank you both for your time and efforts! @anxshi @AnonSky Very much appreciated. Based on a quick glance, a lot of what I'm seeing from Scoop mentions `installation` - @anxshi can Scoop also handle updates? I think that's probably the most important thing to solve here in terms of proper Windows support *(though, obviously, having an easier way to install/manage Phoenix on Windows is still very welcome)*.

anxshi commented 2025年09月18日 20:35:30 +02:00

You're very welcome

can Scoop also handle updates?

Yes, this is handled through the autoupdate property in the manifest

There are many ways how to install phoenix via scoop, in this implementation I took an example of how a fedora user would probably install phoenix:

1. add the repo
2. choose rpm phoenix or flatpak phoenix depending on the current firefox installation
3. install phoenix

The way I implemented this via scoop:

1. add the bucket
2. install phoenix
   (if user has already installed firefox through scoop, the files get copied on there respective place there;
   if user hasn't installed firefox through scoop, firefox scoop package gets installed as dependency)

This is only one way to do it, there are many more valid ones possible.

You're very welcome > can Scoop also handle updates? Yes, this is handled through the autoupdate property in the manifest There are many ways how to install phoenix via scoop, in this implementation I took an example of how a fedora user would probably install phoenix: 1. add the repo 2. choose rpm phoenix or flatpak phoenix depending on the current firefox installation 3. install phoenix The way I implemented this via scoop: 1. add the bucket 2. install phoenix (if user has already installed firefox through scoop, the files get copied on there respective place there; if user hasn't installed firefox through scoop, firefox scoop package gets installed as dependency) This is only one way to do it, there are many more valid ones possible.

celenity commented 2025年09月19日 16:43:48 +02:00

Yes, this is handled through the autoupdate property in the manifest

Great! This sounds very promising.

(if user has already installed firefox through scoop, the files get copied on there respective place there;
if user hasn't installed firefox through scoop, firefox scoop package gets installed as dependency)

How is scoop downloading/installing Firefox, and where's it getting it from? Does Scoop make any changes/customizations? Does it install Firefox to the same default location that Firefox usually does on Windows? (If you're not sure, I can take a look to confirm when I have time).

> Yes, this is handled through the autoupdate property in the manifest Great! This sounds very promising. > (if user has already installed firefox through scoop, the files get copied on there respective place there; if user hasn't installed firefox through scoop, firefox scoop package gets installed as dependency) How is scoop downloading/installing Firefox, and where's it getting it from? Does Scoop make any changes/customizations? Does it install Firefox to the same default location that Firefox usually does on Windows? *(If you're not sure, I can take a look to confirm when I have time)*.

anxshi commented 2025年09月19日 21:47:21 +02:00

How is scoop downloading/installing Firefox, and where's it getting it from?

you can take a look at the manifests in the known buckets (the ones packaged with scoop on a fresh install, you can enable). For example, by executing scoop install firefox it downloads firefox from "https://archive.mozilla.org/pub/firefox/releases/[...]"

You can inspect the manifest here: https://github.com/ScoopInstaller/Extras/blob/master/bucket/firefox.json
Their wiki is also very helpful: https://github.com/ScoopInstaller/Scoop/wiki/App-Manifests

Does Scoop make any changes/customizations?

As far as I know, no.

Does it install Firefox to the same default location that Firefox usually does on Windows?

No, but it's pretty similar to an portable installation of firefox.
The folder layout is as following:

%USERPROFILE%\scoop - per user root location (default). Can be overridden via %SCOOP%.
%ProgramData%\scoop - root location of apps installed for all users. Can be overridden via %SCOOP_GLOBAL%.
...\scoop\apps - installed applications
...\scoop\apps\scoop - the Scoop application itself
...\scoop\buckets - manifests of installable apps (also a git clone of the bucket source repositories)
...\scoop\cache - the downloaded installers
...\scoop\persist - persisted application files
...\scoop\shims - added to PATH, wrappers that point to the installed applications

See: https://github.com/ScoopInstaller/Scoop/wiki/Scoop-Folder-Layout

> How is scoop downloading/installing Firefox, and where's it getting it from? you can take a look at the manifests in the known buckets (the ones packaged with scoop on a fresh install, you can enable). For example, by executing `scoop install firefox` it downloads firefox from "https://archive.mozilla.org/pub/firefox/releases/[...]" You can inspect the manifest here: https://github.com/ScoopInstaller/Extras/blob/master/bucket/firefox.json Their wiki is also very helpful: https://github.com/ScoopInstaller/Scoop/wiki/App-Manifests > Does Scoop make any changes/customizations? As far as I know, no. > Does it install Firefox to the same default location that Firefox usually does on Windows? No, but it's pretty similar to an portable installation of firefox. The folder layout is as following: ``` %USERPROFILE%\scoop - per user root location (default). Can be overridden via %SCOOP%. %ProgramData%\scoop - root location of apps installed for all users. Can be overridden via %SCOOP_GLOBAL%. ...\scoop\apps - installed applications ...\scoop\apps\scoop - the Scoop application itself ...\scoop\buckets - manifests of installable apps (also a git clone of the bucket source repositories) ...\scoop\cache - the downloaded installers ...\scoop\persist - persisted application files ...\scoop\shims - added to PATH, wrappers that point to the installed applications ``` See: https://github.com/ScoopInstaller/Scoop/wiki/Scoop-Folder-Layout

celenity commented 2025年09月25日 03:35:28 +02:00

Apologies for the late reply here. Thanks for sharing that manifest @anxshi.

Would it be possible for the scoop to install Phoenix to Firefox's standard Windows locations, in addition to the Scoop-specific ones? For instance, for Phoenix's Linux packages, I usually set it to install the files at /etc/firefox, but for some files, I also create symlinks where necessary for common install locations, like /opt/firefox, /usr/lib/firefox, and /usr/lib64/firefox.

The main files specifically I'd like to see if we can install to both Firefox's standard location and the Firefox's Scoop-specific one are:

• distribution/policies.json
• defaults/pref/phoenix.js
• phoenix.cfg

The location of Phoenix's remaining files isn't really important, so we can keep those in some kind of standard location (Could probably just be left at the standard Scoop location for Phoenix).

In general, I think I'd rather avoid explicitly setting Firefox from Scoop as a dependency for Phoenix's Scoop package (though I'd definitely like to ensure Phoenix does work with Scoop's Firefox package), because there's a lot of factors to consider there. For instance, some users may prefer to use Firefox's EME-free variant (Which is what we'd recommend macOS/Windows users use if possible - in general, I need to document the recommended methods of installation/set-up for Firefox itself), some users may just prefer to install Firefox directly from Mozilla, some users may just already have Firefox installed from some other mechanism and may not want to re-install it through Scoop, etc.

Thanks again for your time here, this seems very promising! I think this may be how we can finally support Windows...

Apologies for the late reply here. Thanks for sharing that manifest @anxshi. Would it be possible for the scoop to install Phoenix to Firefox's standard Windows locations, in addition to the Scoop-specific ones? For instance, for Phoenix's Linux packages, I usually set it to install the files at `/etc/firefox`, but for some files, I also create symlinks where necessary for common install locations, like `/opt/firefox`, `/usr/lib/firefox`, and `/usr/lib64/firefox`. The main files specifically I'd like to see if we can install to both Firefox's standard location and the Firefox's Scoop-specific one are: - `distribution/policies.json` - `defaults/pref/phoenix.js` - `phoenix.cfg` The location of Phoenix's remaining files isn't really important, so we can keep those in some kind of standard location *(Could probably just be left at the standard Scoop location for Phoenix)*. In general, I think I'd rather avoid explicitly setting Firefox from Scoop as a dependency for Phoenix's Scoop package *(though I'd definitely like to ensure Phoenix does work with Scoop's Firefox package)*, because there's a lot of factors to consider there. For instance, some users may prefer to use Firefox's `EME-free` variant *(Which is what we'd recommend macOS/Windows users use if possible - in general, I need to document the recommended methods of installation/set-up for Firefox itself)*, some users may just prefer to install Firefox directly from Mozilla, some users may just already have Firefox installed from some other mechanism and may not want to re-install it through Scoop, etc. Thanks again for your time here, this seems very promising! I think this may be how we can finally support Windows...

anxshi commented 2025年10月13日 22:52:26 +02:00

I'm very sorry for the long wait... I really should enable email notifications here.

It's been a while and i tried tinkering a bit and learning more about scoop. Although I'd say I'm still an amateur, I'll try answring u're question as best as i can.

Would it be possible for the scoop to install Phoenix to Firefox's standard Windows locations, in addition to the Scoop-specific ones?

At first, i thought this is out of scope but now I think this can be done, even if it is tricky or a rather complex approach, but i do believe scoop can copy data almost everywhere (considering if we run an elevated command). I'll come back to this.

About the the installation and the location of the files of the phoenix suite:
the simplest form including auto-updates is to setup the manifest to check for new releases of phoenix, if a new version is released, the manifest updates its version by itself. Considering we added the bucket that includes the phoenix manifest and type "scoop install phoenix-suite" scoop will install the newest release from github (or whatever we configure). In my experimental manifest I made it only download the windows stuff only by extracting it.
This will download the zip from the newest release and extract the windows dir inside to the default scoop app location.
I consider this the the bare minimum, auto-updating phoenix for windows.

In general, I think I'd rather avoid explicitly setting Firefox from Scoop as a dependency for Phoenix's Scoop package

In the end, totally. Perfectly would be if the Installation Process can check for any kind of firefox Installation and copy phoenix's files to the correct path. Like i said in the beginning, I think this is possible with scoop but pretty complex and I'm sadly way to inexperienced for now.
Providing a simple Phoenix-Suite for Windows that auto-updates (either only the files and or bundled with firefox-eme-free) is a huge step I'd say.

Thanks again for your time here, this seems very promising! I think this may be how we can finally support Windows...

No need to thank me, but thank u for giving life to phoenix! <3
I'll try to stay active and look what i can do, I really think it's possible to bring phoenix to windows users

I'm very sorry for the long wait... I really should enable email notifications here. It's been a while and i tried tinkering a bit and learning more about scoop. Although I'd say I'm still an amateur, I'll try answring u're question as best as i can. > Would it be possible for the scoop to install Phoenix to Firefox's standard Windows locations, in addition to the Scoop-specific ones? At first, i thought this is out of scope but now I think this can be done, even if it is tricky or a rather complex approach, but i do believe scoop can copy data almost everywhere (considering if we run an elevated command). I'll come back to this. About the the installation and the location of the files of the phoenix suite: the simplest form including auto-updates is to setup the manifest to check for new releases of phoenix, if a new version is released, the manifest updates its version by itself. Considering we added the bucket that includes the phoenix manifest and type "scoop install phoenix-suite" scoop will install the newest release from github (or whatever we configure). In my experimental manifest I made it only download the windows stuff only by extracting it. This will download the zip from the newest release and extract the windows dir inside to the default scoop app location. I consider this the the bare minimum, auto-updating phoenix for windows. > In general, I think I'd rather avoid explicitly setting Firefox from Scoop as a dependency for Phoenix's Scoop package In the end, totally. Perfectly would be if the Installation Process can check for any kind of firefox Installation and copy phoenix's files to the correct path. Like i said in the beginning, I think this is possible with scoop but pretty complex and I'm sadly way to inexperienced for now. Providing a simple Phoenix-Suite for Windows that auto-updates (either only the files and or bundled with firefox-eme-free) is a huge step I'd say. > Thanks again for your time here, this seems very promising! I think this may be how we can finally support Windows... No need to thank me, but thank u for giving life to phoenix! <3 I'll try to stay active and look what i can do, I really think it's possible to bring phoenix to windows users

anxshi commented 2026年04月01日 23:49:34 +02:00

It's been a while but I have put more thoughts in how to distribute Phoenix for the Windows crowd, but i don't have particulary great news unfortunately.

Scoop

I've tried out various ways and Scoop can definitely keep Phoenix updated for the user and install the files to the default Firefox Installation. However, people who have firefox installed with scoop get thrown under the bus for now, due to the way Scoop manages its updates. A workaround for this is force-updating the phoenix package manually, so it gets reapplied.

Winget

I don't have much experience with the way winget handles its manifests but after testing it out a while I feel it's not possible and very much not intended to apply or even move data different from where winget installs its packages.

Conclusion

Scoop is very promising although there're some quirks that could be tackled and worked around. The alternative would be to distribute a custom script or a wrapper of some sort.

It's been a while but I have put more thoughts in how to distribute Phoenix for the Windows crowd, but i don't have particulary great news unfortunately. ## Scoop I've tried out various ways and Scoop can definitely keep Phoenix updated for the user and install the files to the default Firefox Installation. However, people who have firefox installed with scoop get thrown under the bus for now, due to the way Scoop manages its updates. A workaround for this is force-updating the phoenix package manually, so it gets reapplied. ## Winget I don't have much experience with the way winget handles its manifests but after testing it out a while I feel it's not possible and very much not intended to apply or even move data different from where winget installs its packages. ## Conclusion Scoop is very promising although there're some quirks that could be tackled and worked around. The alternative would be to distribute a custom script or a wrapper of some sort.

anxshi commented 2026年04月04日 19:32:43 +02:00

After some more brainstorming and testing, I came up with this experimental Scoop manifest that should work for everyone. It's not optimized yet but I should do the minimum:

• Keep Phoenix updated
• Apply Phoenix on any Firefox Installation of choice (not restricted to only scooped Firefox)
• Remember Firefox Installation path beyond updates

I'm really happy I got this to work somehow and I hope this can help us get closer to make Phoenix easily accessable for Windows Users.

You can test the manifest by either downloading it (scoop install 'path\to\manifest.json') or get it through this experimental bucket: https://github.com/anxshi/various-infills

After some more brainstorming and testing, I came up with this experimental Scoop manifest that should work for everyone. It's not optimized yet but I should do the minimum: - Keep Phoenix updated - Apply Phoenix on any Firefox Installation of choice (not restricted to only scooped Firefox) - Remember Firefox Installation path beyond updates I'm really happy I got this to work somehow and I hope this can help us get closer to make Phoenix easily accessable for Windows Users. You can test the manifest by either downloading it (scoop install 'path\to\manifest.json') or get it through this experimental bucket: https://github.com/anxshi/various-infills

celenity commented 2026年04月04日 23:25:48 +02:00

@anxshi Thank you so much for your time and work on here!

I just tested it on a VM (with Firefox installed from Scoop), and I'm getting:

Linking ~\scoop\apps\phoenix\current => ~\scoop\apps\phoenix2円026.03.31.1
Persisting InstallConfig.ini
Running post_install script...Copy-Item:
Line |
 23 | Copy-Item "$dir\phoenix.cfg" "$firefoxPath" -Force | Out-Null
 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current'.
Copy-Item:
Line |
 24 | Copy-Item "$dir\defaults\pref\phoenix.js" "$firefoxPath\defaults\pref ...
 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current\defaults\pref'.
done.
'phoenix' (2026年03月31日.1) was installed successfully!

From Scoop, Firefox appears to have installed for me at C:\Users\User\scoop\apps\firefox. After installing your phoenix scoop, I do notice it placed a policies.json file at C:\Users\User\scoop\apps\extras\firefox\current\distribution\policies.json.

I do also notice:

Notes
-----
Please be aware to run 'scoop update phoenix --force' after every Scoop Firefox update.

I wonder if there's a way we can better handle this - maybe we can also make it copy the necessary files at boot?

---

I also tried uninstalling Firefox from Scoop, and instead installed it from ftp.mozilla.org directly (which installed it to C:\Users\User\AppData\Local\Mozilla Firefox). After then uninstalling and reinstalling your phoenix scoop, it didn't prompt me to choose the installation directory like it did before, and it just gave me:

phoenix-windows.zip (467.9 KB) [==============================================================================] 100%
Checking hash of phoenix-windows.zip ... ok.
Extracting phoenix-windows.zip ... done.
Running pre_install script...done.
Linking ~\scoop\apps\phoenix\current => ~\scoop\apps\phoenix2026円.03.31.1
Persisting InstallConfig.ini
Running post_install script...Copy-Item:
Line |
 24 | Copy-Item "$dir\defaults\pref\phoenix.js" "$firefoxPath\defaults\pref ...
 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current\defaults\pref'.
done.
'phoenix' (2026年03月31日.1) was installed successfully!

I also noticed the same issue with Firefox installed to C:\Program Files\Mozilla Firefox as well.

@anxshi Thank you so much for your time and work on here! I just tested it on a VM *(with Firefox installed from Scoop)*, and I'm getting: ```sh Linking ~\scoop\apps\phoenix\current => ~\scoop\apps\phoenix2026円.03.31.1 Persisting InstallConfig.ini Running post_install script...Copy-Item: Line | 23 | Copy-Item "$dir\phoenix.cfg" "$firefoxPath" -Force | Out-Null | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current'. Copy-Item: Line | 24 | Copy-Item "$dir\defaults\pref\phoenix.js" "$firefoxPath\defaults\pref ... | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current\defaults\pref'. done. 'phoenix' (2026年03月31日.1) was installed successfully! ``` From Scoop, Firefox appears to have installed for me at `C:\Users\User\scoop\apps\firefox`. After installing your `phoenix` scoop, I do notice it placed a `policies.json` file at `C:\Users\User\scoop\apps\extras\firefox\current\distribution\policies.json`. I do also notice: ```sh Notes ----- Please be aware to run 'scoop update phoenix --force' after every Scoop Firefox update. ``` I wonder if there's a way we can better handle this - maybe we can also make it copy the necessary files at boot? ___ I also tried uninstalling Firefox from Scoop, and instead installed it from `ftp.mozilla.org` directly *(which installed it to `C:\Users\User\AppData\Local\Mozilla Firefox`)*. After then uninstalling and reinstalling your `phoenix` scoop, it didn't prompt me to choose the installation directory like it did before, and it just gave me: ```Installing 'phoenix' (2026年03月31日.1) [64bit] from 'various-infills' bucket phoenix-windows.zip (467.9 KB) [==============================================================================] 100% Checking hash of phoenix-windows.zip ... ok. Extracting phoenix-windows.zip ... done. Running pre_install script...done. Linking ~\scoop\apps\phoenix\current => ~\scoop\apps\phoenix2026円.03.31.1 Persisting InstallConfig.ini Running post_install script...Copy-Item: Line | 24 | Copy-Item "$dir\defaults\pref\phoenix.js" "$firefoxPath\defaults\pref ... | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current\defaults\pref'. done. 'phoenix' (2026年03月31日.1) was installed successfully! ``` I also noticed the same issue with Firefox installed to `C:\Program Files\Mozilla Firefox` as well.

anxshi commented 2026年04月05日 12:43:55 +02:00

@celenity thx for responding and testing!

---

Line |
 23 | Copy-Item "$dir\phoenix.cfg" "$firefoxPath" -Force | Out-Null
 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current'.
Line |
 24 | Copy-Item "$dir\defaults\pref\phoenix.js" "$firefoxPath\defaults\pref ...
 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current\defaults\pref'.

The mistake here came from the pre_install script when scooped firefox apps get fetched and appname gets both values of $appname and $bucket. This is also why the later problem occured.

Line |
 24 | Copy-Item "$dir\defaults\pref\phoenix.js" "$firefoxPath\defaults\pref ...
 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current\defaults\pref'.

I also tried uninstalling Firefox from Scoop, and instead installed it from ftp.mozilla.org directly (which installed it to C:\Users\User\AppData\Local\Mozilla Firefox). After then uninstalling and reinstalling your phoenix scoop, it didn't prompt me to choose the installation directory like it did before [...]

This is intended behaviour. It saves ur previous selection in the ini file and persits it for updates. To remove persisted data u have to 'scoop uninstall --purge phoenix'.

---

I do also notice:

Notes
-----
Please be aware to run 'scoop update phoenix --force' after every Scoop Firefox update.

I wonder if there's a way we can better handle this - maybe we can also make it copy the necessary files at boot?

I have to say this problem is annoying, but only affects users who use a scooped firefox. Since Scoop creates a new version folder each update of a package, phoenix files get left behind, so it needs to be reapplied manually. We need to find a way to know if scoop updates firefox to then run 'scoop update firefox --force' automatically. I need to look more into this, but this workaround is the best we have know. Probably a scheduled task or a powershell Hook can be helpful in this case.

---

Thank you again for sharing these problems. I fixed them, added notes for more clearence and a condition in post_uninstall that checks if $firefoxPath exists.

Btw, just to clarify. the checkver and autoupdate section are optional. You can absolutely update the manifest version by urself or via codeberg i'm pretty sure.

I've attached the fixed manifest here again and it should be updated in my experimental bucket.

EDIT: Removed the manifest, because it's messy comparing to the newer manifests.

@celenity thx for responding and testing! ___ ``` Line | 23 | Copy-Item "$dir\phoenix.cfg" "$firefoxPath" -Force | Out-Null | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current'. Line | 24 | Copy-Item "$dir\defaults\pref\phoenix.js" "$firefoxPath\defaults\pref ... | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current\defaults\pref'. ``` The mistake here came from the pre_install script when scooped firefox apps get fetched and appname gets both values of $appname and $bucket. This is also why the later problem occured. ``` Line | 24 | Copy-Item "$dir\defaults\pref\phoenix.js" "$firefoxPath\defaults\pref ... | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Could not find a part of the path 'C:\Users\User\scoop\apps\extras\firefox\current\defaults\pref'. ``` > I also tried uninstalling Firefox from Scoop, and instead installed it from ftp.mozilla.org directly (which installed it to C:\Users\User\AppData\Local\Mozilla Firefox). After then uninstalling and reinstalling your phoenix scoop, it didn't prompt me to choose the installation directory like it did before [...] This is intended behaviour. It saves ur previous selection in the ini file and persits it for updates. To remove persisted data u have to 'scoop uninstall --purge phoenix'. ___ > I do also notice: > > ``` > Notes > ----- > Please be aware to run 'scoop update phoenix --force' after every Scoop Firefox update. > ``` > > I wonder if there's a way we can better handle this - maybe we can also make it copy the necessary files at boot? I have to say this problem is annoying, but only affects users who use a scooped firefox. Since Scoop creates a new version folder each update of a package, phoenix files get left behind, so it needs to be reapplied manually. We need to find a way to know if scoop updates firefox to then run 'scoop update firefox --force' automatically. I need to look more into this, but this workaround is the best we have know. Probably a scheduled task or a powershell Hook can be helpful in this case. ___ Thank you again for sharing these problems. I fixed them, added notes for more clearence and a condition in post_uninstall that checks if $firefoxPath exists. Btw, just to clarify. the checkver and autoupdate section are optional. You can absolutely update the manifest version by urself or via codeberg i'm pretty sure. I've attached the fixed manifest here again and it should be updated in my experimental bucket. EDIT: Removed the manifest, because it's messy comparing to the newer manifests.

anxshi commented 2026年04月09日 21:54:31 +02:00

Me again with a quick update,

I completely redone the manifest. Scoop provides many useful functions available for the scripts in the manifest.json, and I barely make use of these in the previous one. I would say it's now very clean and native regarding scoop's philosophy. For now this variant is for scooped firefox only, but I will take a look on how to achieve a clean manifest including support for non-scoop Firefox Installations.

btw notice that i've removed the note regarding force updating every firefox update in order to reapply phoenix. This isn't needed anymore for every update, only for ur first installation.

Me again with a quick update, I completely redone the manifest. Scoop provides many useful functions available for the scripts in the manifest.json, and I barely make use of these in the previous one. I would say it's now very clean and native regarding scoop's philosophy. For now this variant is for scooped firefox only, but I will take a look on how to achieve a clean manifest including support for non-scoop Firefox Installations. btw notice that i've removed the note regarding force updating every firefox update in order to reapply phoenix. This isn't needed anymore for every update, only for ur first installation.

anxshi commented 2026年04月13日 12:56:52 +02:00

Hi,
so i'm pretty happy with the outcome of these manifests. One for users who use firefox installed through scoop and one for the ones who have firefox installed the traditonal way. I'll probably experiment how a combined manifest could look like.

I should probably make a repo instead of uploading the manifest here.

Although this is a pretty neat way of distributing Phoenix for Windows Users, it leaves behind people who are not willing to install Scoop just for Phoenix - which is totally fine. Due to how restricted winget manifest seems to be, a custom install script is most likely needed.

Hi, so i'm pretty happy with the outcome of these manifests. One for users who use firefox installed through scoop and one for the ones who have firefox installed the traditonal way. I'll probably experiment how a combined manifest could look like. I should probably make a repo instead of uploading the manifest here. Although this is a pretty neat way of distributing Phoenix for Windows Users, it leaves behind people who are not willing to install Scoop just for Phoenix - which is totally fine. Due to how restricted winget manifest seems to be, a custom install script is most likely needed.

koru commented 2026年04月13日 16:57:02 +02:00

@anxshi wrote in #3 (comment):

Although this is a pretty neat way of distributing Phoenix for Windows Users, it leaves behind people who are not willing to install Scoop just for Phoenix - which is totally fine. Due to how restricted winget manifest seems to be, a custom install script is most likely needed.

What about Chocolatey and WinGet (yeah, WinGet isn't best tool) distribution?

Chocolatey Docs: Create packages

@anxshi wrote in https://codeberg.org/celenity/Phoenix/issues/3#issuecomment-13066059: > Although this is a pretty neat way of distributing Phoenix for Windows Users, it leaves behind people who are not willing to install Scoop just for Phoenix - which is totally fine. Due to how restricted winget manifest seems to be, a custom install script is most likely needed. What about [Chocolatey](https://chocolatey.org) and [WinGet](https://learn.microsoft.com/en-us/windows/package-manager/winget) (yeah, WinGet isn't best tool) distribution? [Chocolatey Docs: Create packages](https://docs.chocolatey.org/en-us/create/create-packages)

anxshi commented 2026年04月13日 22:01:53 +02:00

@ivankopylov6603 I totally would like to see Phoenix getting distributed through WinGet (especially because it's part of the OS), but as far as i tested and understand how manifests work, it cannot be done. Please feel free to correct me if i'm wrong.

Chocolatey on the other Hand would work, I guess. I've used it for some time in the past, but when winget became a native part of Windows and Scoop's Philosophy excited me very much, i dropped choco.

@ivankopylov6603 I totally would like to see Phoenix getting distributed through WinGet (especially because it's part of the OS), but as far as i tested and understand how manifests work, it cannot be done. Please feel free to correct me if i'm wrong. Chocolatey on the other Hand would work, I guess. I've used it for some time in the past, but when winget became a native part of Windows and Scoop's Philosophy excited me very much, i dropped choco.

anxshi commented 2026年04月22日 09:58:42 +02:00

Hey again!
Looking back two weeks ago, I completely reworked the manifests into a much more mature way to install phoenix.

Also, I've recently mirrored my scoop bucket repo to codeberg: https://codeberg.org/anxshi/various-infills
You'll find 3 different manifests, being "phoenix.json", "phoenix-system.json" and "phoenix-unified.json". Basically, they only differ in where they look for firefox Installations.

phoenix.json
Intended for users that have firefox installed with scoop.

phoenix-system.json
Intended for users that have firefox installed in a traditional way.

phoenix-unified.json
Firefox installation agnostic - Works with scoop and traditional installs.

---

I tested them quite a bit and they all seem pretty stable.
@celenity, feel free to play around with them - especially phoenix-unified.json should be pretty much what we were looking for.
If you do consider distributing Phoenix (and perhaps even Dove) via Scoop, be aware that the (not mandatory!!) autoupdate mechanic for bucket repos depends on GitHub Action's - a bucket repo is also available for users if there's just manifests inside. Though, I tinkered around a bit with Codeberg's CI capabilities but i couldn't wrap my head around it.

That's all for now

Hey again! Looking back two weeks ago, I completely reworked the manifests into a much more mature way to install phoenix. Also, I've recently mirrored my scoop bucket repo to codeberg: https://codeberg.org/anxshi/various-infills You'll find 3 different manifests, being "phoenix.json", "phoenix-system.json" and "phoenix-unified.json". Basically, they only differ in where they look for firefox Installations. [phoenix.json](https://codeberg.org/anxshi/various-infills/src/branch/main/bucket/phoenix.json) Intended for users that have firefox installed with scoop. [phoenix-system.json](https://codeberg.org/anxshi/various-infills/src/branch/main/bucket/phoenix-system.json) Intended for users that have firefox installed in a traditional way. [phoenix-unified.json](https://codeberg.org/anxshi/various-infills/src/branch/main/bucket/phoenix-unified.json) Firefox installation agnostic - Works with scoop and traditional installs. --- I tested them quite a bit and they all seem pretty stable. @celenity, feel free to play around with them - especially phoenix-unified.json should be pretty much what we were looking for. If you do consider distributing Phoenix (and perhaps even Dove) via Scoop, be aware that the (not mandatory!!) autoupdate mechanic for bucket repos depends on GitHub Action's - a bucket repo is also available for users if there's just manifests inside. Though, I tinkered around a bit with Codeberg's CI capabilities but i couldn't wrap my head around it. That's all for now

degausser commented 2026年07月11日 16:20:05 +02:00

@anxshi since your issue tracker for various-infills is on github ( :( ), i'll ask you here instead:

does scoop support setting environment variables in {pre,post}_install stages? if yes, you could set some of the phoenix environment variables too, namely something like:

[Environment]::SetEnvironmentVariable("MOZ_GFX_CRASH_MOZ_CRASH", 1, "User")
[Environment]::SetEnvironmentVariable("MOZ_DISABLE_ASAN_REPORTER", 1, "User")
[Environment]::SetEnvironmentVariable("MOZ_CRASHREPORTER_DISABLE", 1, "User")
[Environment]::SetEnvironmentVariable("MOZ_CRASHREPORTER_NO_REPORT", 1, "User")
[Environment]::SetEnvironmentVariable("MOZ_CRASHREPORTER_URL", "data;", "User")

replace "User" with "Machine" if system (instead of user) environment variables are preferred (probably not). removal of set variables in pre_uninstall would be a bit tricky though (setting them to "" is not the same as removal, see the setx docs).

@anxshi since your issue tracker for `various-infills` is on github ( :( ), i'll ask you here instead: does scoop support setting environment variables in `{pre,post}_install` stages? if yes, you could set some of the phoenix [environment variables](https://codeberg.org/celenity/Phoenix/src/branch/dev/linux/etc/profile.d/phoenix-env-overrides.sh#L19-L36) too, namely something like: ```pwsh [Environment]::SetEnvironmentVariable("MOZ_GFX_CRASH_MOZ_CRASH", 1, "User") [Environment]::SetEnvironmentVariable("MOZ_DISABLE_ASAN_REPORTER", 1, "User") [Environment]::SetEnvironmentVariable("MOZ_CRASHREPORTER_DISABLE", 1, "User") [Environment]::SetEnvironmentVariable("MOZ_CRASHREPORTER_NO_REPORT", 1, "User") [Environment]::SetEnvironmentVariable("MOZ_CRASHREPORTER_URL", "data;", "User") ``` replace `"User"` with `"Machine"` if _system_ (instead of _user_) environment variables are preferred (probably not). removal of set variables in `pre_uninstall` would be a bit tricky though (setting them to `""` is not the same as removal, see the [setx docs](https://ss64.com/nt/setx.html#:~:text=To%20delete%20an%20environment%20variable)).