There are many suggestions on the web what the structure of the Python project can/shall be, e.g. What is the best project structure for a Python application?.
"proj-dir"
+- doc
+- apidoc
+- scripts
+- "src-dir"
+- tests
It seems that many people in the Python world prefer the "src-dir" and "proj-dir" to be equal (or very similar). However, the scripts and tests will surely have to import some modules from src-dir, so either I have to
run all scripts and tests when proj-dir as my current working dir, or
the PYTHONPATH must contain the proj-dir, right?
Or, is there any other possibility which I overlook now?
Suppose I have such structure and have set up the PYTHONPATH correctly. Now I commit the project into VCS and another developer checks the project out. On his machine the PYTHONPATH will not be set properly and the imports in scripts and in tests will not work.
Is there any possibility to somehow make the PYTHONPATH definition part of the project, so that it can be part of the version control?
Is there a different project structure that would allow me to make checkout and start using the project without modifying the PYTHONPATH?
Is to solution suggested here: Python - How to PYTHONPATH with a complex directory structure? (i.e. to include a short sys.path modifying snippet in every script and test) the right one?
Would a site module http://docs.python.org/2/library/site.html be of any help?
What is your workflow when developing a project with a similar structure?
Even through project structure is complex and testcases uses src in different package, you can add PYTHONPATH in Environmental Variables in Windows
My Computer --> Properties --> System Properties --> Advanced Tab --> Environmental Variables. Add new System Variable PYTHONPATH and append your projects dir to that variable with delimiter ';'
I suggest you to keep readme.txt to your project which clearly says to how to add PYTHONPATH in order to run the scripts. It is as similar as adding PATH of android-sdk to make adb shell to work, adding Java path to make Java to work in command prompt
Thus readme.txt helps to run the script when downloaded in different machine with only one change(adding PYTHONPATH variable with value = projectpath)
No need to add all modules of src in order to make testcases to work which is using src
Here is an example proj structure:
SAMPLEPROJECT
src
com
sample
example
utils
a.py
b.py
testcases
test1.py
test2.py
res
docs
If test1.py test case is using a.py and and b.py:
Dont add utils module to PYTHONPATH, as you already added project path to python path your import statement looks something like this in test1.py
from src.com.sample.example.utils import a.py
from src.com.sample.example.utils import b.py
Related
I am new in the cmake world and I am not even sure if what I try to achieve is possible or not.
Currently, I have an eclipse project file which contains many targets (they have some files in common, some are different (I used the exclusions in Eclipse to do it)).
One of my colleague uses the CLion for that so he created a CmakeLists.txt files for that. Is it possible to use these CmakeLists.txt files to create a project in eclipse? Is it possible to have this way a multiple targets in one project file?
Is it possible to use these CmakeLists.txt files to create a project in eclipse?
Yes, use the following from your source root to generate Eclipse project files which support in-source builds.
$ cmake -G"Eclipse CDT4 - Unix Makefiles" .
If you want to do out-of-source builds, there are a few wrinkles to be aware of. Have a look at this cmake wiki page about the Eclipse CDT generator for more details.
Note that Eclipse also supports importing projects from existing makefiles, which means you can just use the "Unix Makefile" generator to generate makefiles, and import from those.
See this cmake wiki page for details on that
Is it possible to have this way a multiple targets in one project file?
Yes it is. All targets specified in your CMakeLists.txt file(s) will be included in the generated project file.
Thank you for a quick answer. I looked into what you sent me but my indexing still does not work. In my project I have following structure:
Folder main with main.c
Folder platform with three different folders: folder a with a.c file, folder b with b.c file and folder c.c file, and one platform.h file common for all those files with declaration of function "platform()". The main function calls the function "platform()" from platform.h which definition is different for each target (a, b, and c respectively defined in a.c, b.c and c.c file). When I create the eclipse project I do get the folder called "[Targets]" but the indexing does not work which means it does not show me the function from the proper target.
Is it possible to be able to switch from one target to another with the "hammer" sign?
Many thanks.
Newcomer to the Intellij IDE here, with no Java background. I've looked at Build Definition to get a brief idea on how should I organize my scala files, but their example doesn't cover the full structure of an SBT-based project shown attached.
Can you advise what each folder should be used for (e.g. where my source files should go, etc.) and also point me to sources where I can go read up more.
Thanks so much
It is described pretty well here:
http://www.scala-sbt.org/0.13.5/docs/Getting-Started/Directories.html
But to sum up.
.idea:
This contains the project files for your idea project, and has nothing directly to do with sbt itself. However idea (if auto refresh is enabled) updates its own project, each time the sbt build files change.
project:
This contains the sbt project files, except for the main build file (files ending in .sbt). Sbt build is itself based on scala, and if you need to have some scala code included in your build (e.g., code-generation/meta-programming, pre-compiler macros), then you can place scala source files in this directory. The code of these files can be used in your build system, and is not part of your project itself. To really understand how a build is made, then you will need to understand the difference in how sbt files and scala files for the build should be placed. When you run sbt, then it will search for .sbt files in the directory your are standing in, when these are found, it will search for scala files in the project directory. These files together are the source of the build system, but because these are source files, they need to be built before they can be used. To build this build system, sbt uses sbt. So a build system to build the build system is needed. It therefore looks for sbt files inside the project directory, and scala files for this build inside project/project and build these files to get a build system, that can build the build system (that can build your project). Actually it can continue recursive down to any project/project/project... directory, until it finds a project folder containing no scala files, and therefore needs no building before use.
The target folder inside project, is the target folder for the sbt build of your build definition. See below what a target folder is.
Normally you would not need to be concerned about this; just remember that build.sbt in your root directory is the build script for your project. project/plugins.sbt defines plugins activated for your build system, and project/build.properties contains special sbt properties. Currently the only sbt property I now of, is what version of sbt should be used.
src:
This is where your place the source files of your project. You should place any java sources in src/main/java, scala sources in src/main/scala. Resources are placed in src/main/resources.
The src/main/scala_2.11 folder is typically used, if you have some code that it not binary compatible with different versions of scala. In such cases you would be able to configure sbt to use different source files when building for different versions of scala. You probably do not need this, so I would advise to just delete the src/main/scala_2.11 folder.
Test sources are placed inside src/test/java and source/test/scala, and test resources are placed in src/test/resources.
target
This folder is the target folder for sbt. All compiled files, generated packages and so on are placed somewhere inside this dir.
Most things in this dir are not so interesting, as most of it is just internal sbt things. However if your build a jar file by calling sbt package, then it will be placed inside target/scala-x (where x is the scala version). There are also a lot of different plugins, that can package your application in different ways, and they will normally also place the package files somewhere inside the target dir.
I currently have a multiproject SBT build with 2 projects under it, one of which has a dependency on the other. The dependent one has a test in which it needs to load a file from a certain directory structure underneath its working directory. It uses a relative path in a configuration file to designate this directory structure.
The issue is that depending on whether I am running this test through my IDE (with working directory at the subproject level) or at the SBT umbrella project level (with working directory at the umbrella level) makes a difference in the ability of my test to load this file via its relative path and succeed.
I need to use a relative path so that other developers working on this project may use the checked-in code out of the box, and duplicating the directory structure and contained files at two levels in the project is out of the question. What I really need to do is direct SBT to move the working directory into the subproject when doing tests, so that the directory structure can remain the same regardless of where the test is initiated from.
SBT offers a ForkOptions class (http://www.scala-sbt.org/0.13.0/api/index.html#sbt.ForkOptions), further described here: http://www.scala-sbt.org/0.13/docs/Forking.html at the bottom of the page, through which it seems one can supply a working directory for the forked JVM to be started in but gives no good examples on how to set up the configuration in a root build.sbt or supply a ForkOptions instance to a test task.
Does anyone have any experience using this class, and/or can anyone offer some guidance on getting this functionality out of a multiproject build in SBT?
The solution is to provide the following settings to the project definition in the root build.sbt.
lazy val yourProject = project.settings(
fork := true,
baseDirectory in test := file("yourProject")
)
These cause the JVM to fork for the tests in that subproject and changes the working directory to the base of that subproject.
I've got a rather large project set up in intellij. The project uses scala scripts to specify various instances of the program.
It used to be the case that the scala scripts were in a resources directory of the project, but, this is not ideal. I've moved them, so my project looks like this (the idea is, ultimately, to move them away completely)
+Project root
+subproject
+src.main.resources
[Scripts were here]
pom
iml
pom
iml
+scripts
[scripts are now here]
but now intellij syntax highlighting does not recognise the scripted imports relating to the project. Is there some way of getting intellij to recognise the dependency of these scripts without going back to a module structure and the src/main/resources folder?
Define scripts as a source folder:
File > Project Structure > Modules > Sources
and mark scripts as Sources (blue icon).
You can find more info on IntelliJ WebHelp.
Question
Is there a way to reliably ensure that both the python source paths and compiled java class paths are added to the Jython PythonPath when running unit tests under eclipse?
If not, is there a better workaround than adding absolute paths to the PyDev PythonPath, External Libraries list?
Background
I have been having a strange problem with running Jython unit tests on a Jython class which inherits from a Java class.
We have an eclipse RCP application with a structure (simplified) like this:
Config project (Pydev nature only)
scripts
src
classes.py
test
classesTest.py
Core project (Both Java & Pydev natures)
scripts
src
baseClass.java
classes
baseClass.java
Library project (Both Java & Pydev natues, but no Jython scripts)
src
interface.java
classes
interface.class
In classes.py I import baseClass, which implements an interface defined in interface.java. I then create a Jython class which inherits from baseClass.
In my classesTest.py, I import classes and define the unit tests.
The problems come when I try to run the unit tests using "Project explorer > classesTest.py > Run as > Jython unit-test":
Sometimes it is unable to find the baseClass (I think it fails with an ImportError, but I can't reproduce this right now).
At other times it finds the baseClass, but then can't find the interface, so it fails with a java.lang.NoClassDefFoundError.
If I pprint the sys.path at the start of the test module, then I can see that:
While core/scripts is on the python path, neither core/classes nor library/classes are on the path.
Both core/scripts and core/classes are on the python path, but library/classes still is not.
Sometimes, very rarely, both classes paths are added to the python path and the unit tests work fine, without the workaround below. Unfortunately, I haven't worked out how to reproduce this and can see no difference in the files in the source tree between it working and it not working.
Current Workaround
My current workaround is to explicitly add in "External Libraries" for library/classes and core/classes explicitly. Unfortunately it appears that these have to be absolute paths, which means I have to set them differently for every trunk, branch or computer that I use. As such, I don't want to commit these into revision control and it is a pain having to set them up every time.
Notes
Note that the Config project only references the core project, but referencing the library project explicitly makes no difference to the class path.
Also, while trying to find a reliable method to reproduce this problem, I had other libraries inexplicably disappear from the python path and then just as mysteriously reappear, the most recent example being Mock!
Update
I haven't seen this problem recently (currently using Eclipse 3.7.1 & PyDev 2.2.2) so it may have been an aberration with the combination of Eclipse/PyDev I was using at the time.
For a java project, you have to explicitly add the folder with the .class files to the PYTHONPATH.
The recommended organization would be:
java_project/bin <- this folder should be set as a source folder within PyDev (to be added to the PYTHONPATH).
java_project/src <- this folder should be added to the jdt classpath, but should not have any reference in PyDev
python_project/src <- this folder should be set as a source folder within PyDev (to be added to the PYTHONPATH).
And the python_project should have a reference to the java_project.
See the last part of http://pydev.org/manual_101_project_conf2.html as a reference.
I had a similar problem. Recently resolved by accordingly modifying the python.path field in the Jython registry file.
It looks like the Pydev plugin cannot modify the sys.path to be able to import the Python module from a Java project in Eclipse.
More details at Adding in a python module to the sys.path for a Java project in pydev, Eclipse