Mac/Linux installation methods

[willcohen]

Hello, I'm looking into potentially running a file through this for the first time, and therefore looking into getting this installed on Mac/Linux. Based on the install instructions, it sounds like the user base of this tool is still almost entirely Windows-based. Are there any objections to (or perhaps more importantly, is there any interest in) me looking into a way to get this packaged up for a more automated installation/uninstallation for mac/linux via nixpkgs?

[cpeel]

tl;dr: yes!

We would welcome changes to make this easier to install on non-Windows systems, macOS in particular. In addition, anything we could also use for packing guiguts (which is also a Tcl/Tk perl package) would be a huge boon. We're starting to see more macOS users and the current set of instructions can often be a huge lift for non-developers.

For Linux it's a tradeoff of making it easier for those users to install but not adding a lot of maintenance overhead. I'm assuming Linux users are already pretty friendly with installing dev packages, etc.

Finally, we need to consider the release packaging environment with whatever non-Windows release packages we create. @windymilla, the maintainer of guiguts and as the last-person-who-touched-it guiprep, is on Windows with MinGW and does not have access to a Mac.

[willcohen]

Okay! I've been able to get it to build and run on mac with nix -- ultimately making just making an executable script that runs the perl file after installing all the dependencies -- and will try it out to see if I can work out any bumps as I try processing my first file. I might also try looking at if there's anyway to update the Tk library to allow for running on native Mac. XQuartz does kind of work, but it's a real drag for anyone who's not savvy with X11 already, and I feel like there's a few possibilities like Tcl::pTk (though it's not quite working for me yet) that might allow bypassing XQuartz altogether.

[srjfoo]

I'm happy to do testing.

[cpeel]

I might also try looking at if there's anyway to update the Tk library to allow for running on native Mac. XQuartz does kind of work, but it's a real drag for anyone who's not savvy with X11 already, and I feel like there's a few possibilities like Tcl::pTk (though it's not quite working for me yet) that might allow bypassing XQuartz altogether.

I played Tcl::pTk a couple of years ago for guiguts without success -- and it's a surprisingly hard lift. I would love to get us moved off of the no-longer-maintained perl::Tk. I keep thinking we're going to be forced into it at some point when something breaks but not yet!

[windymilla]

I played Tcl::pTk a couple of years ago for guiguts without success -- and it's a surprisingly hard lift. I would love to get us moved off of the no-longer-maintained perl::Tk. I keep thinking we're going to be forced into it at some point when something breaks but not yet!

Yes, I agree - we had to stop people installing the latest Strawberry Perl a year or so back because Perl/Tk wouldn't install properly with it. Luckily that was eventually fixed in Perl/Tk. Next time, it could be the final straw

[willcohen]

Sounds good. I had to comment out some things and so the functionality isn't quite there without me actually kicking the tires some more, but I've at least been able to get it to load with pTk, so I know this is generally doable and will allow for removing Xquartz entirely!

Separately, is there a way we can get a proper license on this code? Will probably be needed to get it packaged somewhere.

[willcohen]

@windymilla does your windows computer have the ability to run WSL? (ie Windows 10 or 11?) If so, I can work on getting all the perl packages merged into nixpkgs needed as prereqs for guiprep (and hopefully guiguts). I should be able to then in an eventual PR to switch to pTk also include instructions to install Nix on Mac, Linux, or Windows-via-WSL. The benefit there is that anyone who's got Nix installed will be able to with one command fully replicate an identical cross-platform development environment needed to run off the git repo's development version, which may help spread some development load across interested parties. It's still probably best to retain the older dev/installation method for Windows to avoid shaking things up unnecessarily (ie Strawberry Perl), but I suspect it'll help an alternate method to have something consistent across platforms to help troubleshoot when evaluating PRs from non-Windows users.

[windymilla]

Slightly complicated answer: although the computer I use does have Windows 10, it belongs to work, so I couldn't run WSL on it. However, since I am retiring in July, I will be getting a new computer of my own in the next couple of months, on which I should be able to run WSL. Although I have some historical Linux experience, at the moment, I'm limited to using Gitbash or MinGW under Windows. Needless to say, I have no experience with WSL or Nix.

As far as I know, @cpeel is the only person who has experience of using/developing guiprep/guiguts on more than one platform. He would no doubt be able to comment more accurately on whether the benefits of what you're suggesting would repay the investment needed.

For context, of the almost 500 guiguts PRs from the last 3½ years, only maybe 4 or 5 relate to things that behaved differently on different platforms, that is, they were reported from a non-Windows user, and I couldn't reproduce under Windows. I've done the vast majority of the development over that period (with able assistance from @cpeel and others) although guiguts dates back over 10 years, and has had substantial periods where no-one was supporting/developing it. So I would be very happy if others were interested in getting involved.

[windymilla]

By the way, congrats on getting a version of guiprep running with pTk!

[willcohen]

@windymilla noted -- that all makes lots of sense.

I'll try to find a Windows machine that I can put Strawberry Perl on, just to confirm that I can get it going with pTk that way too before suggesting a PR. I'll still need your assistance testing it once I make a PR, since I'm less familiar with this software toolchain and it's essential that the primary developer not have any regressions!

[windymilla]

@willcohen - thanks
Note that although I have made a few small fixes to guiprep, I've never used it in anger - I don't do PM work. It was only because I had taught myself perl in order to do guiguts development, that I picked up a couple of issues that guiprep users wanted fixing.
So, although I might spot a major problem, I might not spot others. There are people who do use guiprep under Windows though, who I'm sure would be willing to trial a new test version.
At some later point, if you get guiprep working with Strawberry Perl and pTk, it would be good to have a discussion about what might be needed to get guiguts working. That can definitely wait though!

[cpeel]

Nice job on getting pTk working! 🎉 Starting with guiprep and taking lessons learned to guiguts is a great path forward.

I'll get a license added to the repo, thanks for calling that out.

I should be able to then in an eventual PR to switch to pTk also include instructions to install Nix on Mac, Linux, or Windows-via-WSL

Slightly complicated answer: although the computer I use does have Windows 10, it belongs to work, so I couldn't run WSL on it.

Does Nix on Windows require WSL? If so that might be a challenge for many Windows users, either due to running on frighteningly-old versions of Windows or restrictions imposed by others. I don't think this should prevent us from moving forwards, but it probably means we do need to retain the StrawberryPerl-based approach for that platform.

It sounds like there are 2 related but separate things in play:

• Nix support
• pTk support

Does Nix support require pTk support? Both sound good to me but I would prefer PRs that tackle them separately to isolate changes and more focus testing.

[willcohen]

Good questions. Nix might require pTk but I'm okay with just trying to tackle pTk on Windows for now, since that's the much heavier lift. I'm looking into the Strawberry Perl method, and the issue seems to be that it's really hard to get Tcl to build with Strawberry Perl, which is a prereq for pTk. So far I've tried installing ActiveState TCL on Windows, but Strawberry Perl fails with the following:

cpanm (App::cpanminus) 1.7044 on perl 5.032001 built for MSWin32-x64-multi-thread
Work directory is C:\Users\wcohen/.cpanm/work/1654104612.30996
You have make C:\Strawberry\c\bin\gmake.exe
You have LWP 6.52
Falling back to Archive::Tar 2.38
Searching Tcl::pTk () on cpanmetadb ...
--> Working on Tcl::pTk
Fetching http://www.cpan.org/authors/id/C/CA/CAC/Tcl-pTk-1.09.tar.gz
-> OK
Unpacking Tcl-pTk-1.09.tar.gz
Entering Tcl-pTk-1.09
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (7.58)
Configuring Tcl-pTk-1.09
Running Makefile.PL

##################### Warning ####################################
Your Tcl/Tk installation does not appear to include the Tix package.
Tix is needed for full compatibility with perl/tk.
Build can continue, but some functionality will be missing.

Information on Tix can be found at http://tix.sourceforge.net
Warning: prerequisite Tcl 0.90 not found.
Checking if your kit is complete...
Looks good
Generating a gmake-style Makefile
Writing Makefile for Tcl::pTk
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::MakeMaker 0 ... Yes (7.58)
Checking if you have Tcl 0.90 ... No
Checking if you have Class::ISA 0.36 ... Yes (0.36)
Checking if you have Sub::Name 0.05 ... Yes (0.26)
Checking if you have Time::HiRes 0 ... Yes (1.9764)
==> Found dependencies: Tcl
Searching Tcl (0.90) on cpanmetadb ...
--> Working on Tcl
Fetching http://www.cpan.org/authors/id/V/VK/VKON/Tcl-1.27.tar.gz
-> OK
Unpacking Tcl-1.27.tar.gz
Entering Tcl-1.27
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (7.58)
Configuring Tcl-1.27
Running Makefile.PL
incpath -IC:\TEMP\ActiveState----------------------------------------please-run-the-install-script----------------------------------------\include from your tclconfig C:/ActiveTcl/lib/tclConfig.sh does not provide tcl.h at Makefile.PL line 36.
tclsh=C:/ActiveTcl/bin/tclsh.exe
tclConfig.sh=C:/ActiveTcl/lib/tclConfig.sh
tcl_library=C:/ActiveTcl/lib/tcl8.6
tcl_version=8.6
Using config data in C:/ActiveTcl/lib/tclConfig.sh
-> N/A
-> FAIL Configure failed for Tcl-1.27. See C:\Users\wcohen\.cpanm\work\1654104612.30996\build.log for details.
-> FAIL Installing the dependencies failed: Module 'Tcl' is not installed
-> FAIL Bailing out the installation for Tcl-pTk-1.09.

[willcohen]

Never mind, got it. ActiveState TCL is still needed, but for some reason the install misconfigured the tclConfig.sh file for me, so I had to override the variables that said things like -----please-run-the-install-script------- to point to various folders in C:\ActiveTcl\.... With that and an adjusted install_cpan_modules.pl:

Looks like Strawberry will work just fine -- easier than I thought!

[windymilla]

Great progress! Do you think that what you had to do would need to be done by each person who wanted to use guiprep or guiguts on Windows, or is it too early to tell?

[willcohen]

@windymilla unclear -- it definitely appears to be a bug (https://community.activestate.com/t/activetcl-install-script-please-run-the-install-script/9067/3).

After I submit a PR for this (let me actually try doing CP on something now that I've got a working program, which was the original goal!), I may need someone else on Windows to install ActiveState Tcl themselves and see if it works okay for them. It could definitely be a my-computer-only problem.

[windymilla]

I'm definitely up for trying that out when needed. Enjoy using guiprep for actual prep work!

[srjfoo]

I'm happy to do independent Mac testing -- at least as far as bringing it up and providing independent verification that the different installation method works on a Mac. (Also for guiguts when it gets to that point.)

[willcohen]

Lovely. Just as a minor update, working on getting the perl package prereqs added to Nix (NixOS/nixpkgs#175775) -- currently working on Mac but still trying to resolve getting perl's Tcl to link to the actual libtcl.so on Linux. With that as a working base even as a PR, I can use that as a stable environment to work on cleaning up the .pl file on the Mac side over (hopefully) the next few weeks.

I suspect that in the end there'll be a set of hopefully-not-too-many substitutions that just need to be applied to a bunch of various components to get it working with pTk. With any luck, enumerating them here through this process will make guiguts a much more straightforward update. I see no reason, at the moment, that there will be anything there that precludes it from a similar upgrade that also allows for dropping XQuartz on Mac and sprucing up the UI on Windows!

[willcohen]

A PR for pTk is now present with #30.

Given the discussion around installation on Mac for guiguts, I may also start working on that shortly!

[willcohen]

For whatever it's worth, as has been clarified in this thread, MUCH more work will be needed, but my new CP mentor has pointed out the value of using guiguts for CP work too depending on the harvested source, so I'm going ahead and giving that port a shot too. Many things still broken but I can at least get it to load a window under pTk:

[willcohen]

Now that I think I've got #30 working without as many workarounds for Windows users, I'm going to pick back up with trying to get guiguts going this way too, trying to get enough components of it running to successfully prep a book on Mac so I know it's working correctly.

[windymilla]

Thanks @willcohen - do let me know if there's anything in the depths of guiguts that doesn't make sense or can't easily be ported. I may know either the history or the importance of the feature.

[srjfoo]

I'm happy to test it, too, but I'm not an active PPer, so I'd probably only hit some of the high points. It wouldn't be a bad idea to get an actual Mac PPer on board to do more rigorous testing.