Thread: [Pydev-users] Treatment of external sources within the workspace
Brought to you by:
fabioz
From: Rickard P. <Ric...@je...> - 2010-02-04 16:51:28
|
Hello, I am looking at the problem of setting up Pydev where I have a number of files part of the project and a large number of files that are really only to consider as a library. The current set-up is that "my" files are in the "Source Folders", and "their"(=library) files are in the "External Libraries". Now, a large number of legacy Python code exist in the library that relies on C modules that are not loadable. This cause a problem, which it took me quite a while to find out the reason for, namely that code analysis is run on the library -- of course generating thousands of error markers. The obvious choice is to include the magic string (@PydevCodeAnalysisIgnore) in all files that should skip analysis. But I think that in many cases that is not possible, or at least cumbersome. Consider, for example, a large number of files in a third party RCS. The solution is simple: I just move out the external sources outside of the project hierarchy, so that Eclipse no longer considers them as Resources. No analysis will be made for these resources anymore, but they will still resolve thanks to the "External Libraries" record. Which leaves me at the question: Is there any particular reason for this behavior? It was not what I as a user would have expected to happen. (I suppose for some users, it is also not always possible to move external sources away, for example when the files are part of a build process that is hard to change.) To better illustrate the problem, I have created a small script that generates a folder "pyproj" in the CWD. Import into Eclipse. Thanks for your time reading all this babbling :) // Rickard ---- BEGIN generate.py ----- import os srcdir = "./pyproj/src" os.makedirs(srcdir) alphabet = "abcdefghijklmnopqrstuvwxyz" for x in range(1,10): libdir = "./pyproj/lib/folder%02d" % x os.makedirs(libdir) for y in alphabet: for z in alphabet: f = file(libdir + "/mod%s%s.py" % (y,z), "w") print >>f, "# Module %s%s" % (y,z) print >>f, "import _MyCLibrary" print >>f, "" print >>f, "def myfunc():" print >>f, " return _MyCLibrary.myfunc()" print >>f, "" f.close() f = file(srcdir + "/source%02d.py" % x, "w") print >>f, "# Source file %02d" % x print >>f, "import folder%02d.modcc as libmod" % x print >>f, "" print >>f, "def callmyfunc():" print >>f, " return libmod.myfunc()" print >>f, "" f.close() f = file("./pyproj/.project","w") print >>f, """<?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>pyproj</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.python.pydev.PyDevBuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.python.pydev.pythonNature</nature> </natures> </projectDescription> """ f.close() f = file("./pyproj/.pydevproject","w") print >>f, """<?xml version="1.0" encoding="UTF-8" standalone="no"?> <?eclipse-pydev version="1.0"?> <pydev_project> <pydev_property name="org.python.pydev.PYTHON_PROJECT_VERSION">python 2.6</pydev_property> <pydev_property name="org.python.pydev.PYTHON_PROJECT_INTERPRETER">Default</pydev_property> <pydev_pathproperty name="org.python.pydev.PROJECT_SOURCE_PATH"> <path>/pyproj/src</path> </pydev_pathproperty> <pydev_pathproperty name="org.python.pydev.PROJECT_EXTERNAL_SOURCE_PATH"> <path>%s</path> </pydev_pathproperty> </pydev_project> """ % os.path.abspath("./pyproj/lib") f.close() ---- END generate.py ----- |
From: Fabio Z. <fa...@gm...> - 2010-02-04 17:02:54
|
2010/2/4 Rickard Petzäll <Ric...@je...>: > Hello, > > I am looking at the problem of setting up Pydev where I have a number of > files part of the project and a large number of files that are really only > to consider as a library. The current set-up is that "my" files are in the > "Source Folders", and "their"(=library) files are in the "External > Libraries". > > > > Now, a large number of legacy Python code exist in the library that relies > on C modules that are not loadable. This cause a problem, which it took me > quite a while to find out the reason for, namely that code analysis is run > on the library -- of course generating thousands of error markers. > > > > The obvious choice is to include the magic string (@PydevCodeAnalysisIgnore) > in all files that should skip analysis. But I think that in many cases that > is not possible, or at least cumbersome. Consider, for example, a large > number of files in a third party RCS. > > > > The solution is simple: I just move out the external sources outside of the > project hierarchy, so that Eclipse no longer considers them as Resources. No > analysis will be made for these resources anymore, but they will still > resolve thanks to the "External Libraries" record. > > > > Which leaves me at the question: Is there any particular reason for this > behavior? It was not what I as a user would have expected to happen. (I > suppose for some users, it is also not always possible to move external > sources away, for example when the files are part of a build process that is > hard to change.) > The problem is that Pydev will analyze any file that's in your eclipse project in the PYTHONPATH (source folder or external library)... The idea is that you should only keep the files you're changing in the project... Other dependencies should be somewhere else. If you really want to keep them in an eclipse project but don't want to analyze them, an option might be adding them in a .zip file (although I haven't tested it). Still, if that's a common scenario, I agree that this could be changed (it's really a bit strange that things in the external libraries are analyzed, so, feel free to open a bug-request for that). Cheers, Fabio |
From: Rickard P. <Ric...@je...> - 2010-02-04 17:19:55
|
> -----Original Message----- > From: Fabio Zadrozny [mailto:fa...@gm...] > Sent: den 4 februari 2010 18:03 > To: pyd...@li... > Subject: Re: [Pydev-users] Treatment of external sources within the > workspace > > 2010/2/4 Rickard Petzäll <Ric...@je...>: > > Hello, > > > > I am looking at the problem of setting up Pydev where I have a number > of > > files part of the project and a large number of files that are really > only > > to consider as a library. The current set-up is that "my" files are > in the > > "Source Folders", and "their"(=library) files are in the "External > > Libraries". > > > > > > > > Now, a large number of legacy Python code exist in the library that > relies > > on C modules that are not loadable. This cause a problem, which it > took me > > quite a while to find out the reason for, namely that code analysis > is run > > on the library -- of course generating thousands of error markers. > > > > > > > > The obvious choice is to include the magic string > (@PydevCodeAnalysisIgnore) > > in all files that should skip analysis. But I think that in many > cases that > > is not possible, or at least cumbersome. Consider, for example, a > large > > number of files in a third party RCS. > > > > > > > > The solution is simple: I just move out the external sources outside > of the > > project hierarchy, so that Eclipse no longer considers them as > Resources. No > > analysis will be made for these resources anymore, but they will > still > > resolve thanks to the "External Libraries" record. > > > > > > > > Which leaves me at the question: Is there any particular reason for > this > > behavior? It was not what I as a user would have expected to happen. > (I > > suppose for some users, it is also not always possible to move > external > > sources away, for example when the files are part of a build process > that is > > hard to change.) > > > > The problem is that Pydev will analyze any file that's in your eclipse > project in the PYTHONPATH (source folder or external library)... The > idea is that you should only keep the files you're changing in the > project... Other dependencies should be somewhere else. If you really > want to keep them in an eclipse project but don't want to analyze > them, an option might be adding them in a .zip file (although I > haven't tested it). > > Still, if that's a common scenario, I agree that this could be changed > (it's really a bit strange that things in the external libraries are > analyzed, so, feel free to open a bug-request for that). > > Cheers, > > Fabio > Thank you for the quick response! Bug filed, https://sourceforge.net/tracker/?func=detail&aid=2946047&group_id=85796&atid=577329 Cheers, Rickard |