-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Windows #49
Comments
Thanks for reporting the issue! Could you try applying that patch and running tests? In documentation there should be instructions how to do that |
You are welcome On 2013-06-10 17:44, Domen Kožar wrote:
|
I have a hard time running the tests, I created a venv with Going into mr.bob/test and doing "nosetest" brings heaps of violations and failures, some messages seems to hint toward running nosetest with specific parameters but I did not guess witch ones yet. I am doing my test on Windows so it might be the problem, I had no time to test under one of my FreeBSD systems yet. Is there a how-to do tests or should it work "right away" ? |
http://mrbob.readthedocs.org/en/latest/developer.html#running-tests On Tue, Jun 11, 2013 at 10:26 PM, Annakan [email protected] wrote:
|
ok shame on me for not seing that but the missing parts where mostly the sphinx and pep compliance part if I am not mistaken and the error number is nearly the same (probably the same in fact) to be completely sure I redid the whole install from scratch on windows I add to do without it Many of the errors seems to be temp file logic related and probably of the same class of error I tried to fix. here is the complete test result FYI
|
Thanks. I'll get around eventually and test this on a Windows box. If someone else wants to give it a shot - go for it! |
I started digging on it a bit. Firstyou assumed than any ":" in a "pathname" would denote a "python_package" relative path specifier, but it happens than on windows ":" is present in every absolute file names since windows file names are of the form if ':' in template_name and not os.path.exists(template_name):
path = resolve_dotted_path(template_name)
else:
path = os.path.realpath(template_name) It is an ugly fix that assume no python package will be a one letter name that correspond (accidentally) to a real path name but .... SecondWe have subtle bug (or documented corner case) in six "u" function used in rendering.py, render_structure(), that happen to be the reason that sometimes on some paths and windows system mr.bob where not generating anything silently for me on other computers (to my dismay). The documentation here http://pythonhosted.org/six/index.html?highlight=u#six.u contains just the right amount of warning to confuse me about the safe usage of this function (there seem to be none to me since the call can be made upon any kind of data, that could happen not to be ASCII, this is a function with no guarantee and no way of making any) I did not see a good way out of this right away so will postpone a fix till tomorrow, my intuition is that this transformation is happening too late anyway, we should move to and from Unicode at the edges of the application (input and output parameters) and not in the middle of the function (where sanity checks are less likely). I need to sleep on it ;) |
FYI I was able to fix a class of bugs pertaining on managing tempfiles on windows (it seems you can open a file twice on unix with the same process but not on windows, top of my head hypothesis not tested). I need to test my "unicode fix" with python3 and on unix. I have trouble in the test with mock (I hate mock as much as I love it ) who seems hellbent on considering urlretrieve must be called with two parameters when only one is possible but it must be confusing what is truly patched (often the case with mock). I will see if I can solve those remaining tests and test on Python3 on Windows at least. |
Hi @Annakan, any progress on this? |
Hello sorry for the delay in answering, busy summer busy days. |
I'm curious what the status of this issue is. This has become a blocker for Windows compatibility. It looks to me like the |
@iandennismiller as far as I know there are no more problems with windows. At least I know that people use the plone-templates in https://github.com/plone/bobtemplates.plone with windows. |
I can report that
We are making this work by using a relative pathname, so it's no longer a blocker on Windows for us. However, I wanted to follow up to let you know the Windows |
I would accept a PR that asserts |
On windows at least, trying to activate mrbob from an url fail with a I/O error 13, permission denied from urlretrieve in configurator.py / parse_template.
The reason is that urlretrieve expect to open in write mode the file name passed in and fail since tempfile.NamedTemporaryFile already did that.
it seems that (temp_file_name, heasers)= urlretrieve(url) is enough to get a tempfile with the downloaded content in it. (from http://docs.python.org/2/library/urllib.html)
Something like this seems to do the job
The text was updated successfully, but these errors were encountered: