swc-windows-installer.py: Install nano source syntax highlighters #357
Conversation
This is a no-op merge, explicitly considering and rejecting the de-namespacing from the master branch. After this merge, future merges from the master branch will pick up any content changes. $ git merge --log --no-ff --strategy ours master * master: swc-windows-installer.py: Remove nesting setup/
* master: swc-windows-installer.py: Restore nose entry point
* master: swc-windows-installer.py: Use regular expressions to POSIX-ify paths swc-windows-installer.py: Only create the python-scripts dir if it doesn't exist swc-windows-installer.py: Split out zip_install into its own function
* python: swc-windows-installer.py: Quote $PATH export to account for spaces.
* python: swc-windows-installer.py: Install nano source syntax highlighters
|
@ethanwhite can you please test on Windows? |
|
I did that last week, but it looks like I reported the result in the wrong place (#228 (comment)). Oops. The installation runs smoothly on Windows 7, but I don't see any syntax highlighting on a Python file. What can I do to help you debug? |
|
On Wed, Mar 12, 2014 at 08:28:21AM -0700, Ethan White wrote:
What's in your ~/.nanorc? It should be a series of 'include' The other possibility is that nano is looking somewhere other than |
|
On Wed, Mar 12, 2014 at 08:28:21AM -0700, Ethan White wrote:
Ah, sorry I missed that in my inbox. That's the right place too ;), |
|
On Wed, Mar 12, 2014 at 12:18 PM, W. Trevor King [email protected] wrote:
I didn't have one before, and yes it includes a bunch of includes. For example, These files do exist in the listed directories. |
|
On Wed, Mar 12, 2014 at 01:24:40PM -0700, Ethan White wrote:
That looks reasonable. My next guess is that either nano is not |
|
On Wed, Mar 12, 2014 at 4:40 PM, W. Trevor King [email protected] wrote:
Well, add
If I rename And Process Manager reports failed attempts to access: So it looks like maybe we want to rename to |
|
Got it. We just need to change the |
|
On Wed, Mar 12, 2014 at 04:44:31PM -0700, Ethan White wrote:
Thanks for figuring that out :). I'll work up fixes to the scripts |
* python: swc-windows-installer.py: Use '~' in ~/nano.rc includes swc-windows-installer.py: Rename ~/.nanorc to ~/nano.rc
The nano FAQ hints that this is the prefered path on MS Windows [1], and Ethan White confirmed it in testing [2]. [1]: http://www.nano-editor.org/dist/v2.2/faq.html#3.9.1 [2]: swcarpentry#357 (comment)
On Wed, Mar 12, 2014 at 04:44:31PM -0700, Ethan White wrote [1]: > Got it. We just need to change the `/c/Users/River/` in the include > statements to `~/` and everything works great! [1]: swcarpentry#357 (comment)
The nano FAQ hints that this is the prefered path on MS Windows [1], and Ethan White confirmed it in testing [2]. [1]: http://www.nano-editor.org/dist/v2.2/faq.html#3.9.1 [2]: swcarpentry#357 (comment)
On Wed, Mar 12, 2014 at 04:44:31PM -0700, Ethan White wrote [1]: > Got it. We just need to change the `/c/Users/River/` in the include > statements to `~/` and everything works great! I also replaced an: if [ ... ] condition with: if test ... to match the rest of the script. The underscore prefixes in the string-equality test are to avoid miss interpretation in the pathological case that RCPATH starts with '!' or some such. It's hard to imagine how this could happen with the current script, but... safety first ;). [1]: swcarpentry#357 (comment)
|
On Wed, Mar 12, 2014 at 04:45:56PM -0700, W. Trevor King wrote:
Updated script posted with fd2075f (Merge branch 'python' into |
|
The bash script in #228 is now working properly, but the Python script is still failing. It reports errors like: The obvious difference is that the nano.rc files produced by the bash script have |
* python: swc-windows-installer.py: Use POSIX paths for ~/nano.rc
On Wed, Mar 12, 2014 at 06:34:43PM -0700, Ethan White wrote [1]: > The bash script in swcarpentry#228 is now working properly, but the Python > script is still failing. It reports errors like: > > Error reading ~\.swc\share\nanorc\doc\syntax\python.nanorc > > The obvious difference is that the nano.rc files produced by the > bash script have `/` for paths for the includes, but the Python > script produces includes that use `\`. [1]: swcarpentry#357 (comment)
|
On Wed, Mar 12, 2014 at 06:34:43PM -0700, Ethan White wrote:
Should be fixed now with ee9a596 (swc-windows-installer.py: Use POSIX |
|
Almost there. We now have a line ending issue resulting in: This is fixed by running |
* python: swc-windows-installer.py: Force UNIX-style \n line endings for ~/nano.rc
|
On Thu, Mar 13, 2014 at 03:37:12AM -0700, Ethan White wrote:
Hmm, the presence of '/cygdrive/' hints that you are running this from Anyhow, I've tried to force UNIX-style newlines (\n) with 21a58ad |
|
On Thu, Mar 13, 2014 at 11:46 AM, W. Trevor King [email protected] wrote:
Nope. All the testing was in msysGit. Have a little faith :) I think msysGit
I'm preferential to just supporting this for msysGit since that's our official
I'll try to get to this tonight when I'm back near a Windows machine. |
|
On Thu, Mar 13, 2014 at 08:57:33AM -0700, Ethan White wrote:
Ah good, that halves the number of cases we need to test :). Ignoring |
The link to the commit is broken and I don't seem to be able to track it down quickly. Can you point me in the right direction? |
On Thu, Mar 13, 2014 at 03:37:12AM -0700, Ethan White wrote [1]: > We now have a line ending issue resulting in: > > Error reading /cygdrive/c/Users/... > > This is fixed by running `dos2unix` on the resulting nano.rc. This is also mentioned in the nano FAQ [2]: > Note that the nano.rc file must remain Unix formated in order for > nano to unerstand it. Since Python 3.0 and PEP 3116, Python's open() has taken a 'newline' argument that allows you to override the default line separator for a particular file [3,4]. However, Python 2.x does not support that argument [5]. This commit adds a local 'open3' which uses a terrible hack of a wrapper on Python 2 to fake that support. It opens the file in binary mode, and takes advantage of Python 2's lack of distinction between str and bytes to treat the \n-terminated strings as the raw binary output. That's going to crash and burn if you have any non-ASCII characters in the output content, but we explicitly set all the components in our relative include_path, so that shouldn't be a problem. Another side effect of binary-mode is that we are going to get ASCII-encoded output, not output encoded in the user's preferred encoding (locale.getpreferredencoding [3,6]). That's unfortunate, because nano does the right thing and uses your locale to decode input (at least for UTF-8 locales [7], presumably including your nano.rc file). [1]: swcarpentry#357 (comment) [2]: http://www.nano-editor.org/dist/v2.2/faq.html#3.9.1 [3]: http://docs.python.org/3/library/functions.html#open [4]: http://legacy.python.org/dev/peps/pep-3116/ [5]: http://docs.python.org/2/library/functions.html#open [6]: http://docs.python.org/2/library/stdtypes.html#file.encoding [7]: http://www.nano-editor.org/dist/v2.2/faq.html#5.3
|
On Thu, Mar 13, 2014 at 04:45:17PM -0700, Ethan White wrote:
I just forgot to push :p. Should be fixed now. |
|
It's working great with Python 2. Nice work! I don't have Python 3 on Windows handy, but I'll see if I can get it installed if I have a few spare minutes this weekend. |
|
And... drum roll... works like a charm on Python 3 as well. Go ahead and merge these in whenever you're ready. |
|
Happy to merge, but want to check there's no overlap/conflict with #228. |
|
On Mon, Mar 17, 2014 at 05:04:20AM -0700, Greg Wilson wrote:
There is definitely a conflict with #228 ;). I don't think
Maintaining both scripts in parallel forever is possible, but I'd |
* python: swc-windows-installer.py: Install the sqlite3 shell swc-windows-installer.py: Generalize msysGit download link
|
As per discussion in #424 this should be merged in when someone gets the chance. It will need to be done manually. |
As suggested in #354. Currently untested on Windows ;).
Make writing Python source code (and a number of other languages) a bit more
exciting for the eyes and easier on the brain by coloring strings, comments,
and such.
We need to install the source tarball because the compiled zip doesn't include
the syntax highlighting scripts. To make that easier, I've extracted out the
download / hash-check functionality into a new download(), which I use in both
the old zip_install() and the new tar_install(). If the user doesn't have an
existing ~/.nanorc, we populate it by adding 'include' options for each of the
syntax files in the Nano tarball. If they do have an existing ~/.nanorc, I
assume they know what they're doing ;).
The default '*' compression is for transparent detection 1, but you can
override it to explicitly select the compression type if you like.
There's a bit of ugliness to work around the lack of a
--strip-components analog in TarFile.extractall 2. Instead, we iterate over
the TarInfo members and strip leading components from their 'name' by hand
3.