I'm trying to implement one of the answers to this question. However, I haven't been successful because when I run
> sphinx-autogen -o generated *.rst
I get the errors
Failed to import 'MyMod.X': no module named MyMod.X
Failed to import 'MyMod.Y': no module named MyMod.Y
Failed to import 'MyMod.Z': no module named MyMod.Z
Within my .rst files, there is one with the line:
.. automodule:: MyMod.X
(and similarly for MyMod.Y and MyMod.Z).
I'm running this within a subdirectory docs. In the parent directory containing docs, there is also a subdirectory MyMod which contains __init__.py, X.py, Y.py, and Z.py. The conf.py file within docs has the line sys.path.insert(0, os.path.abspath('../')) immediately after import sys.
The closest related question I can find is this, but the answers there seem to suggest that it is solved by inserting '../' into the path, which I had already done. Also, sphinx-autobuild can find these modules happily, so I don't think this is the issue.
Interestingly, changing the line in my .rst file to be .. automodule:: ../MyMod.X gets rid of the error message, though nothing seems to be generated in the directory I expect, and I then get error messages in sphinx-autobuild.
How can I get sphinx-autogen to read in these modules?
if anyone else has a better answer, or an explanation for this please post it, but here is what I learned about my question
Although sphinx-autogen gives error messages, in the case that I was looking at, the files I was trying to get it to create were still created. While it could not find the modules (and indeed, they were functions, not modules, so it's not a surprise that it couldn't), it still produced the expected output.
Related
I'm getting different results from autodoc when I run sphinx locally (versions 1.6.6 or 2.0.1 on Anaconda Python 3.6.8 for Mac) than when I run it on readthedocs.org (according to their log it's Sphinx version 1.8.5, and probably Python 2.7 since it's launched with python rather than python3).
The difference is in the results from the following file, Shady.Text.rst, which contains no more than:
Shady.Text Sub-module
=====================
.. automodule:: Shady.Text
Now, this sub-module happens to contain only a module-level docstring and no member docstrings—that's as intended, so the corresponding html page should contain the module docstring and no more. And this is exactly what happens when I run make html locally. However the result at https://shady.readthedocs.io/en/latest/source/Shady.Text.html is content-free (header only, no module docstring).
FWIW my autodoc-related entries in conf.py are:
autoclass_content = 'both'
autodoc_member_order = 'groupwise'
What am I doing wrong?
Thanks #StevePiercy for drawing my attention to the crucial lines in the raw log file:
WARNING: autodoc: failed to import module u'Text' from module u'Shady'; the module executes module level statement and it might call sys.exit().
WARNING: autodoc: failed to import module u'Video' from module u'Shady'; the module executes module level statement and it might call sys.exit().
(I had searched the 9000-line log file for .Text, because Text on its creates too many hits, but it hadn't occurred to me to search it for 'Text' in quotes).
To me, the message is misleading: the problem is not that "the module executes module level statements" because that per se is allowed. I wasted some time after noting that some module-level statements seemed to be allowed in other sub-modules, and tried to bundle the offending module-level statements into a class decorator thinking maybe sphinx's mysterious module-level-statement-detector would miss them then...)
No, the problem is that not the fact that the module-level statements exist and might call sys.exit(), but the fact that they did indirectly call sys.exit() during sphinx's compilation procedure. This was a quirk of the way I handle missing dependencies, which should probably be re-thought, but I could work around it for now by avoiding my sys.exit() call when os.environ.get('READTHEDOCS') is truthy.
Basically, my question is, why is it putting an underscore in front of my import path?
It says import path does not begin with hostname which I'm assuming is because it starts with an underscore.
I read somewhere this may have something to do with me screwing up my GOPATH, but I've tried moving it everywhere, inside the project folder, outside the project folder, in the default location, etc.
I'm new to go and this has come up a few times recently. Would appreciate any guidance!
So I was misunderstanding where my source code had to be.
For anyone in the same boat, it needs to be within the go path in the actual src folder.
I found this helpful.
I have created a go script that compiles, starts, checks the status, and ends a web service I created (that is also in go). However, I have come to a road block.
With the compile feature I run the following command:
go install .
Which gives the following error:
./script.go:55: main redeclared in this block
previous declaration at ./hello.go:8
Which makes sense as I have two different files, both with the main func and main package. I also tried moving the script to another folder and then changing the command ran to:
go install {path}
Where {path} is equal to the path I want installed/compiled. Which I then got the following error:
exit status 1: can't load package: package /var/www/test.com/go: import "/var/www/test.com/go": cannot import absolute path
So in conclusion I have thought of only one solution (and I am up to hear others if mine isn't the best approach). My idea is to exclude the script file from compiling with the rest of the files, but I am unsure how to.
I did some research and couldn't find an easy way to do it (such as an --exclude flag with the go install command). Does anybody know how to accomplish what I am trying to achieve?
Thank you.
you could give the hello.go a different package name, that should work. Or i am missing something?
Regards
Tim
I am trying to port a new module into my project. The module has its own make file. I have no background or experience with the make build system, so I decided to use the following command:
make -f Makefile -f ../newmodule/tbt/makefile
But I get the following errors:
../newmodule/tbt/makefile:14: make/macros.mk: No such file or
directory
../newmodule/tbt/makefile:66: *** target file `all' has both : and :: entries. Stop.
Please correct me if I am wrong; it is my understanding that my first error is because I issued make from my main project, and I need to somehow configure it to look into the directory of ../newmodule/tbt/make to find macros.mk. Would anyone be able to suggest an effective way of addressing this issue? What is the best way to include the contents of ../newmodule/tbt/make folder?
My 2nd error seems to be exactly what make complains about, which is having : and :: in the two make files for the target "all". I can not follow the 2nd make file very closely, but there is not much to the lines that have this target. I am thinking of changing it to My_all, and configure this new variable as the default target of the new module. I am not even sure if my terminology is correct. "all" is called the default target for make right? I have reviewed most of the make file document, but it is 5 am, and I do not recall some things.
I came across this error during compilation of some package under OpenWrt. The problem was in the VERSION declaration in the Makefile.
So, check if you have declared anything with unnecessary spaces or comments after some variable.
Removing the comment or space after variables should work.
Try running two separate make -f myMakefile commands, one from each module directory so that the relative paths work out properly as you have already observed that you current directory when executing make may be part of the problem.
Need Solution for the below error. I have dump file to restore in a database. But got a error during import.
IMP-00002: failed to open C:\oracle\product\10.2.0\NEFT_IFSC.dmp for read
Import file: EXPDAT.DMP >
There are lots of things it could be: file path is wrong, file is corrupt, file is too big, permissions on the directory, file name is wrong, and so on.
You may find it helpful to run your import using a parameter file. Not only will that save you some typing if you end up re-running this several times, it will give you the possibility to review what you're about to submit. Find out more.
Also you can set the SHOW=Y parameter to validate the contents of the file.