-
-
Notifications
You must be signed in to change notification settings - Fork 17
provide python? #25
Comments
On Fri, Mar 13, 2015 at 09:23:14AM -0700, Francois Michonneau wrote:
Ah, that's not how I had been thinking aout it (although it would also |
Technically there is a Python install that is packaged with the installer, but it's only accessible to the installer itself. If we want people using the Windows Installer to be able to run the test scripts without installing Python I think it would make the most sense to package them together, but I don't know how that would work off the top of my head and don't have the time to investigate it at the moment. |
This is creating problems for R based workshops because (1) people get the message that they don't have Python and (2) nano isn't configured. |
@r-gaia-cs I agree. If I understand this discussion, I think it's related to my comment in carpentries/workshop-template#136. |
I'm assuming that you mean when the run the checking scripts. If so I think this should be handled in the checking scripts either by having the instructor's comment out the Python check (as is currently recommended) or by improving the reporting to say something like "You have R, but not Python. If this is an R workshop you are good to go."
If nano isn't being configured properly this is a separate issue. The installer should run and install and configure nano, without the need to provide a Python installation that is accessible by the user. |
So, if anyone has been experiencing issues with the nano installation please report them in a separate issue. |
Or did you mean when trying to run the test scripts (sorry for my confusion)? I think there's a bigger question here, which is do we have a reasonable amount of evidence that the check scripts are successfully catching broken installs? If they are, then I think it's worth spending some time making them easier to use, but I'm not currently convinced that adding a Python installation to our Windows installer is the way to go. What about having the check scripts fall back to the already included Python distribution that runs the installer? Any thoughts on this @wking? |
On Sun, Jun 07, 2015 at 02:59:06PM -0700, Ethan White wrote:
There are currently no R checks in the swc-installation-test-2.py |
It's only just now dawining on me (although I know I've been told before) that the Windows installer does not actually install Anaconda, R, etc. Is there are reason we don't do that? I think it would be best. |
On Mon, Jun 13, 2016 at 10:22:00AM -0700, Erik Bray wrote:
Because we don't know if a given workshop is going to need Python or |
The installer could provide options for R, or Python, or both. Most GUI installers should be driveable headlessly, or unpacked in some way or another. I'll look into what it would take for R--for Anaconda I'm certain it can be done. Would it be worth it to go ahead and supersede the Python script with a single installer package with everything bundled in it? This is, for example, how the Docker Toolbox for Windows works. It just has everything bundled in it, and the installer itself unpacks and installs everything needed. |
On Mon, Jun 13, 2016 at 10:37:00AM -0700, Erik Bray wrote:
I don't have access to Windows boxes for testing or much interest in |
Maybe I could keep the Python script, but for the actual GUI installer, rather than having the installer run the Python script, I would run the python script into a build root that's bundled and extracted by the installer. |
On Mon, Jun 13, 2016 at 11:07:58AM -0700, Erik Bray wrote:
That's not going to work for things like ~/.bash_profile appending |
That seems best left as a post-install step performed by the InnoSetup installer. If you want it could still be done by a Python script called from InnoSetup. I think swc-windows-installer would best be broken into install and post-install steps. |
On Mon, Jun 13, 2016 at 11:17:57AM -0700, Erik Bray wrote:
That might work. And if you like you can leave anything that the |
My one annoyance now is that I want to be able to build the installer without py2exe--I tried to set things up so that the installer can be built in Linux under Wine. But I can't seem to run py2exe in that context. Granted I could try to run Python for Windows in Wine; haven't tried that yet. No idea if it would work. |
On Mon, Jun 13, 2016 at 11:35:44AM -0700, Erik Bray wrote:
Wine is also further than I'm motivated to go ;). |
@wking What about Docker? |
On Mon, Jun 13, 2016 at 11:56:32AM -0700, Erik Bray wrote:
The problem is less about installation (if you're suggesting |
Anyways, sorry, I've carried things off topic. The real point of this issue was mainly about running the post-install checks from the installer (including in R workshops). I think that should be easy if we combine the post-install tests and swc-windows-installer.py into a single script, perhaps with some sub-commands. Bundle them all into a single script with py2exe. The first post-install-test would be mostly irrelvant if I bundle Anaconda + R in the installer, with the option for selecting one or the other or both. If Anaconda is installed we can still test the installation, but if only R is installed we can "assume" it's an R workshop and not test for Python (if the user didn't follow instructions and didn't select Python they can uninstall and reinstall or something...) The second post-install test is trickier since it checks for so many different things, configured per workshop. I think the first step may be to have it consume a simple file or command-line options specifying what it should check for. Need to think more about what do from there... |
On Mon, Jun 13, 2016 at 12:19:59PM -0700, Erik Bray wrote:
My preferred solution to this is wking/swc-setup-installation-test#9, |
A question on this--is there a strong reason we need to use Anaconda for Python in the lessons? Is there a lot built around that now? |
It would take a lot to get us off Anaconda - has proven so much easier
than every alternative we've tried for getting a full scientific Python
+ Jupyter notebook stack installed on various machines, and for working
with them afterward. Best to take it as an immovable object for now.
|
@gvwilson I'm fine with keeping it for now if it has definitely made things easier in that regard. I need to test out how well I can integrate it with Cygwin though. I have started a thread on the topic in the mailing list too. |
Is the plan to do a Cygwin-based installer and then give people a chance
to vote it up or down compared to the Git Bash-based system? We ditched
Cygwin for good reasons (mostly to do with the way paths were displayed).
|
I wasn't aware Cygwin was ever tried in the first place. What was the issue with the way paths were displayed? |
@wking can you fill in some history here?
|
@wking suggested here carpentries/workshop-template#173 that the installer could also ship python. That would allow non-python based workshops to run the post-setup scripts (https://github.com/swcarpentry/workshop-template/blob/gh-pages/setup/index.md)
The text was updated successfully, but these errors were encountered: