Okay, so this isn't just about Python, then.
It seems like you have your standard setup that requires:
- GNU Coreutils
- GNU Make
And you've gone far and above most open source projects with a cross-platform environment setup guide:
https://github.com/pinobatch/nrom-templ ... /README.md
So, if you want commentary on this... I guess personally I would have little problem setting this up, especially with these directions, but honestly it's a few steps beyond what I'd want to undertake casually. If I had a need to build one of your things, I'd definitely be willing, but admittedly you've put up an unpleasant barrier here. As it stands, I've often looked at the source code for things you've published, but the only time I've actually set up to build something of yours was when I was getting paid to do it for Haunted Halloween 85.
First and foremost this is obviously Linux-centric. Except for CC65, everything here is easy to get or very standard tools on Linux. Not so on Windows.
One thing I would immediately suggest is not to ask any users to manually modify their PATH, ever. This should simply not be done, except by an installer for a big well maintained stable program. Having to add CC65 to the PATH is a non-starter for me, I refuse to make it a global part of the system. I personally know how to create a temporary PATH in a command environment, but it'd be an annoying work-around. Python on the path is fine. MinGW / MSYS is maybe OK (though they recommend against it, see below). CC65 no.
GNU Coreutils / GNU Make are not very standard on Windows. You probably have them if you're a Windows programmer who needs to build a lot of Linux-centric open source software that doesn't try to make concessions for Windows, but otherwise these just aren't standard toolkit for Windows programming. I don't know what you require from Coreutils but it might be worth trying to drop it as a dependency. Make is less obscure for Windows than Coreutils, but most Windows-centric development environments will do without it.
Your install process directions for these two breaks down entirely. You give a few options:
- You mention MSYS but don't give a link to download. To be honest, I'm not entirely sure what MSYS is, I just think of it as a component of MinGW. The primary website for it seems to be this one which is an absolute nightmare to read.
- You mention Git for Windows, and then some hideous process to add Make. Also not a good solution for this problem. (Maybe you'd be surprised but I think most Windows users of Git are doing it through a GUI like Sourcetree that keeps a local copy of git rather than a globally installed command line tool.)
- You mention devkitPro, which I think is an awful place to get these tools. devkitPro's wiki doesn't even have a clear description of what it is or what it's for. It seems to be about homebrew development for Nintendo consoles GBA and later? This is not even remotely something I'd want to trust to do global installation stuff on my system. Maybe if I was already making homebrew for these other platforms and was familiar with it, but this is too obscure looking for me to be confident its installer won't mess up my system.
I think what you should really recommend to install for this is MinGW
. It's well known, well maintained, and has a relatively nice installer. Only small problem is it doesn't install to your PATH (oops). That's actually good though, because I wouldn't want it to install to my path. I do use MinGW from time to time, but I much prefer keeping it in its own isolated environment. The MinGW Getting Started guide
also recommends this:
The MinGW team do not recommend modifying the system wide Windows PATH variable. We prefer that you use a script to set PATH for the processes on a per session basis.
Alternatively, if you can ditch coreutils the problem becomes much simpler. Just get Make for Windows
. All you need from this is a single EXE. You can drop it locally in the folder. Done. (I think for HH85 I used this + some small modifications to the makefile to get around whatever is in Coreutils.)
Okay, so that was the worst of it.
Python, I think has a mostly easy install process on Windows these days, not going to further comment on that.
Installing Pillow is OK. You need to open a command line, but at least its a command that should reliably work for most people, provided they know what a command line is. Unlike a lot of other Python packages, Pillow has always installed correctly via PIP for me, and I think it's well maintained for that.
Finally CC65. I've already said this above, but don't require this to be a global install, i.e. do not ask users to set their PATH
. Use a local version of it.
Personally I have a lot of CC65 projects, and I use a local copy of CC65 in every one of them. CC65 is not rigorously maintained to be continously backward compatible, and there have been several incidents of this. If I'm working on something I won't allow it to be disrupted by an unnecessary update to the tool.
All of that said, if you have a user install MinGW, there's two approaches that I think might be easy to set up that missing part of the environment:
1. Run C:\MingGW\msys\1.0\msys.bat to open the MSYS shell, which will have access to Coreutils and Make, and they can run this pseudo-Linux environment to build your thing. (I guess put it in your msys home folder.)
2. Create a batch file that sets its own temporary PATH before running Make locally.
So... this turned out pretty long, eh... sorry there was so much to say, but maybe it will help understand what it looks like for at least this particular Windows user to consider building one of your projects.