feat: add makefile

[perrin4869]

I put together a simple makefile and added a desktop file and an icon I found online. This would also help in packaging the app together for different distributions. I can put something together for Slackware, someone could put something together for arch linux maybe? Should help with visibility.

[netbrain]

And to answer you comment on creating different packages, yes that would be great, and I have already created in issue around this #28

The idea was to use nix flake in order to create different target packages and optionally different versions of the docker image.

Like maybe someone would like to have all the zwift files downloaded (as we do today), maybe someone else simply want to have the core zwift and download the zwift files themselves on first run and save it to a volume and continuously update it locally only. Others might want to build zwift entirely from scratch. Others might want to install zwift locally on their host machine instead of going through the container layer. etc ..

all of these options could be created in a nix flake and alternatively also create packages in different distributions, (deb, rpm, etc)

[sHedC]

It might be a better approach to flatpak it? more approachable for non-technical?

[perrin4869]

Well, having a flatpak would be great for convenience, but since you need either docker or podman installed first, I'm not sure it'd be much use?

[sHedC]

https://flathub.org/apps/com.fightcade.Fightcade this uses wine.

[perrin4869]

yeah I think having flatpak that you can click on and run zwift on would be pretty sick and much easier for most people (bar having automatic updates, etc), the only concern I have is that it is a huge departure from the concept of this repo 😅 It's its own separate project almost I think? since it would share little of the code available here

[sHedC]

yeah I think having flatpak that you can click on and run zwift on would be pretty sick and much easier for most people (bar having automatic updates, etc), the only concern I have is that it is a huge departure from the concept of this repo 😅 It's its own separate project almost I think? since it would share little of the code available here

Yes going to ignore it for now would prefer to focus on what is useful for this repo. But might in future just as really fancy learing flatpak stuff.

[sHedC]

Shall I close this then and focus on nix build.

[netbrain]

I'm busy this weekend, but I'll take another look at it next week and see how we best can fit this idea into the project. There is nothing wrong with mixing and matching different tools like make, nix, bash scripts. Just want to make sure we move in the best direction.

[perrin4869]

ok, I removed the makefile. I still think it provides the most intuitive interface to get the files installed into the destination that you want, with the current install.sh it would take more work to get different PREFIX type variables, etc, but if the idea is to always install them as system files into /usr/local, this should be enough

Edit: if there is interest in seeing this script land on AUR for example (it could increase the project visibility for once), I think having a Makefile would be a nice addition to help setup the package, although of course anyone can just copy files on their own

[netbrain]

How about adding a uninstall flag like this?

#!/usr/bin/env bash

# Check if running as root
if [ "$(id -u)" -ne 0 ]; then
    echo "Please run as root"
    exit 1
fi

install_zwift() {
    echo "This will install zwift.sh into /usr/local/bin"
    read -p "Press enter to continue"

    mkdir -p /usr/local/bin
    curl -s -o /usr/local/bin/zwift https://raw.githubusercontent.com/netbrain/zwift/master/zwift.sh
    chmod +x /usr/local/bin/zwift

    mkdir -p /usr/local/share/icons/hicolor/scalable/apps
    curl -s -o /usr/local/share/icons/hicolor/scalable/apps/Zwift\ Logogram.svg https://raw.githubusercontent.com/netbrain/zwift/master/assets/hicolor/scalable/apps/Zwift%20Logogram.svg

    mkdir -p /usr/local/share/applications
    curl -s -o /usr/local/share/applications/Zwift.desktop https://raw.githubusercontent.com/netbrain/zwift/master/assets/Zwift.desktop

    if [[ ":$PATH:" != *":/usr/local/bin:"* ]]; then
        echo "WARNING: Could not find /usr/local/bin on the \$PATH, you might need to add it."
    fi
}

uninstall_zwift() {
    echo "This will remove zwift.sh and associated files"
    read -p "Press enter to continue"

    rm -f /usr/local/bin/zwift
    rm -f /usr/local/share/icons/hicolor/scalable/apps/Zwift\ Logogram.svg
    rm -f /usr/local/share/applications/Zwift.desktop

    echo "Zwift has been uninstalled."
}

if [ "$1" == "uninstall" ]; then
    uninstall_zwift
else
    install_zwift
fi

And also add this to the README?

Also, in terms of packages like deb, rpm, aur or whatnot. Yes sure that would be interesting. But i still think this repo should be the contents of the "source" files just like for instance wine, and then have independent package maintaners that do the actual creation of deb's, rpm's in their own repositories. What do you think?

Feel free to make your own aur repository, there you can add your own customizations as you see fit.

[sHedC]

How about adding a uninstall flag like this?

#!/usr/bin/env bash

# Check if running as root
if [ "$(id -u)" -ne 0 ]; then
    echo "Please run as root"
    exit 1
fi

install_zwift() {
    echo "This will install zwift.sh into /usr/local/bin"
    read -p "Press enter to continue"

    mkdir -p /usr/local/bin
    curl -s -o /usr/local/bin/zwift https://raw.githubusercontent.com/netbrain/zwift/master/zwift.sh
    chmod +x /usr/local/bin/zwift

    mkdir -p /usr/local/share/icons/hicolor/scalable/apps
    curl -s -o /usr/local/share/icons/hicolor/scalable/apps/Zwift\ Logogram.svg https://raw.githubusercontent.com/netbrain/zwift/master/assets/hicolor/scalable/apps/Zwift%20Logogram.svg

    mkdir -p /usr/local/share/applications
    curl -s -o /usr/local/share/applications/Zwift.desktop https://raw.githubusercontent.com/netbrain/zwift/master/assets/Zwift.desktop

    if [[ ":$PATH:" != *":/usr/local/bin:"* ]]; then
        echo "WARNING: Could not find /usr/local/bin on the \$PATH, you might need to add it."
    fi
}

uninstall_zwift() {
    echo "This will remove zwift.sh and associated files"
    read -p "Press enter to continue"

    rm -f /usr/local/bin/zwift
    rm -f /usr/local/share/icons/hicolor/scalable/apps/Zwift\ Logogram.svg
    rm -f /usr/local/share/applications/Zwift.desktop

    echo "Zwift has been uninstalled."
}

if [ "$1" == "uninstall" ]; then
    uninstall_zwift
else
    install_zwift
fi

And also add this to the README?

Also, in terms of packages like deb, rpm, aur or whatnot. Yes sure that would be interesting. But i still think this repo should be the contents of the "source" files just like for instance wine, and then have independent package maintaners that do the actual creation of deb's, rpm's in their own repositories. What do you think?

Feel free to make your own aur repository, there you can add your own customizations as you see fit.

Yes I thought that package maintainers take a repo like this and alter to suite their needs, at least that is how I understood how it works.

[perrin4869]

Done! Please note that if using curl to execute the script, passing the uninstall parameter is not straightforward.

Well, if there is no Makefile available, and someone wants to make a SlackBuild or AUR build script, then yeah, they will just figure out where to put the relevant files and package the program as they think is best. Note that this isn't always obvious, for example, where to place the icon and desktop files, and it could lead to inconsistent packaging in different distros, and people duplicating efforts that could be centralized in a Makefile. Having one is a good measure to have a standard that everyone else can follow. I think if there is a desire to see a program land on AUR, etc, it is a good idea to have a Makefile for those reasons

[sHedC]

Done! Please note that if using curl to execute the script, passing the uninstall parameter is not straightforward.

Well, if there is no Makefile available, and someone wants to make a SlackBuild or AUR build script, then yeah, they will just figure out where to put the relevant files and package the program as they think is best. Note that this isn't always obvious, for example, where to place the icon and desktop files, and it could lead to inconsistent packaging in different repos, and people duplicating efforts that could be centralized in a makefile, to have a standard that everyone else can follow. I think if there is a desire to see a program land on AUR, etc, it is a good idea to have a Makefile for those reasons

Could we make uninstall/ an option e.g. if installed then ask to re-install or uninstall with re-install being the default. or move to two scripts to make copy paste easier?

But if we do the select in the script then would want a bypass as in zwift I have a self updating part.

[perrin4869]

Please feel free to improve on the install script, I'm not really interested much in it personally 😅

[sHedC]

Please feel free to improve on the install script, I'm not really interested much in it personally 😅

ha ha no I have it installed already,

Please feel free to improve on the install script, I'm not really interested much in it personally 😅

ha ha I have it installed already too, was just a thought as ease for end user is the key.

[sHedC]

Please feel free to improve on the install script, I'm not really interested much in it personally 😅

ha ha no I have it installed already,

Please feel free to improve on the install script, I'm not really interested much in it personally 😅

ha ha I have it installed already too, was just a thought as ease for end user is the key.

Actually scrap this, how about just putting a second copy in the readme for uninstall?

[perrin4869]

hm... maybe it's best to take the uninstall part into a separate PR? Or feel free to modify this one, sorry, I'm not really interested in improving it 😅

[sHedC]

hm... maybe it's best to take the uninstall part into a separate PR? Or feel free to modify this one, sorry, I'm not really interested in improving it 😅

works for me happy with what is done and can work on improving if @netbrain is up for that?

I was looking at nix flake and how it can help so flatpak is there as well as appimage and there seems to be a blog on making it distrobution repo friendly (lot to learn).

[netbrain]

Yeah, lets just keep it as is for now. We can in future include uninstall instructions in readme and/or provide a script for it.

[perrin4869]

not to be super persistent, but I think that there were some misconceptions about how package managers usually work package managers rarely will apply changes to the source directory, this is a last-resort measure. The reason is that there are no guarantees that the changes will remain compatible with future versions, and an intent to keep the package as close as possible to the intents of the author

please take a look at one build script from AUR: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=tofi

You can see that this script lists the source file as a tar.gz link to github. This package will then be downloaded, unpacked, and no modifications will be applied to it. You can see also that there is the package function, where the built files will be installed into a predetermined directory, and that directory will go on to be packaged for distribution.

Usually packages that are meant for distribution via deb, rpm, etc, will have some means to create their directory structure inside their source files, it won't usually be left as an exercise to the package maintainers. In the case above, it is using mason and ninja, in other cases it's autotools and sometimes it is just a makefile. Just thought I would try to clear that up.

[sHedC]

not to be super persistent, but I think that there were some misconceptions about how package managers usually work package managers rarely will apply changes to the source directory, this is a last-resort measure. The reason is that there are no guarantees that the changes will remain compatible with future versions, and an intent to keep the package as close as possible to the intents of the author

please take a look at one build script from AUR: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=tofi

You can see that this script lists the source file as a tar.gz link to github. This package will then be downloaded, unpacked, and no modifications will be applied to it. You can see also that there is the package function, where the built files will be installed into a predetermined directory, and that directory will go on to be packaged for distribution.

Usually packages that are meant for distribution via deb, rpm, etc, will have some means to create their directory structure inside their source files, it won't usually be left as an exercise to the package maintainers. In the case above, it is using mason and ninja, in other cases it's autotools and sometimes it is just a makefile. Just thought I would try to clear that up.

Its fine, I got that wrong then, I follow a lot of arguments where maintainers are changing packages and the original maintainers are refusing to deal with issues relating to say xxx distro.

I will check that out, but I am sure then we can use nix flake right?