I am a python beginner, I have Project One which has all the code in a git repo, I am starting a few new projects with their own repos which will all use the generic code in Project One, I don't want to copy paste code. What I am hoping to achieve is separate out the generic code from Project One so it can be inherited/imported in different projects.
generic_Code
-fileOne.py
-fileTwo.py
repo two
Project One
-fileA.py
-fileB.py
repo three
ProjectTwo
-fileC.py
-fileD.py
The goal is I should be able to import classes from Generic_Code repo into files in project one and two. I am using Pycharm and a mac system. On Pycharm, I attached the three projects together and made projectone and two have dependencies to the Generic project, which seem to work but not sure if this is the right way.
Also read something about setup.py but not sure what that is.
I'm following severall tutorials for the sphinx documentation. I.e. this one here:
https://medium.com/#richdayandnight/a-simple-tutorial-on-how-to-document-your-python-project-using-sphinx-and-rinohtype-177c22a15b5b
But whenever I use the sphinx-quickstart command I don't get all options showed in this tutorial and other ones.
I just get these ones:
Selected root path: .
You have two options for placing the build directory for Sphinx output.
Either, you use a directory "_build" within the root path, or you separate
"source" and "build" directories within the root path.
> Separate source and build directories (y/n) [n]: y
The project name will occur in several places in the built documentation.
> Project name: Project Example
> Author name(s): Hello World
> Project release []: 0.1
If the documents are to be written in a language other than English,
you can select a language here by its language code. Sphinx will then
translate text that it generates into that language.
For a list of supported codes, see
https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-language.
> Project language [en]:
Creating file .\source\conf.py.
Creating file .\source\index.rst.
Creating file .\Makefile.
Creating file .\make.bat.
Why are the other options missing?
In the linked tutorial, Sphinx 1.7.5 is used. In Sphinx 2.0.0, the sphinx-quickstart procedure was simplified. Fewer questions are now asked.
Reference: https://github.com/sphinx-doc/sphinx/issues/4148.
I'm climbing my learning curve in Python and try to understand where to put everything.
I originally have a python module in a folder and then a sub folder src, in this src folder I will then have my main source files say main.py then I will have models folder storing my models codes.
/myproject/src/main.py
/myproject/src/models/a-model.py
/myproject/src/models/b-model.py
So my main will import the model like this:
from models.a-model import a
Then when I package the zip file I just zip the myproject folder with that folder structure and deploy and everything is fine.
Now I have another new module doing something different but need to use the same models.
I can easily duplicate them all and code separately and deploy. But I would like to share the codes to the models, so that when one model changes, I only need to update once, instead of 2 places.
My new module is like
/mynew/src/main-b.py
/mynew/src/models/a-model.py
/mynew/src/models/b-model.py
What is the best practise to do this?
Do I put like this?
/myproject/src/main.py
/mynew/src/main-b.py
/models/a-model.py
/models/b-model.py
And then update the import?
But I have doubt how do I deploy? Do I also have to setup the same folder structures?
One would be adding /myproject/src/models to the environment variable PYTHONPATH. Python adds the directories listed in PYTHONPATH environment variable to sys.path, the list of directories where Python searches when you try to import something. This is bad, because modifying PYTHONPATH has its own side effects, fortunately, virtual environments provide a way to get around those side effects.
Alternatively and much better you could add your modules to site-packages directory, site-packages is added to sys.pathby default, this obviates the need to modifyPYTHONPATH. To locate thesite-packages` directory, refer to this page from Python Documentation: Installing Python Modules (Legacy version).
You could also use LiClipse IDE which comes with Pydev already installed. Create source a folder from the IDE and link your previous project with your newer project. When you link your projects the IDE adds the source folders of your older project to the PYTHONPATH of your newer project and thus Python will be able to locate your modules.
I read about Git integration in PyCharm, and created a Git repository from PyCharm. I did this in PyCharm because I was hoping PyCharm would know whether the .idea folder should be ignored, and if that's the case, it would automatically create a .gitignore file with the line .idea/ in it.
But it didn't, so I assumed that I shouldn't ignore the .idea foler. However, I did a quick search and found someone's example .gitignore file, here, which clearly ignores the .idea folder.
So, my question is, should the .idea folder be ignored or not?
Ignoring the whole .idea folder is not necessarily the best idea. There's a number of similar discussions here about this.
How to deal with IntelliJ IDEA project files under Git source control constantly changing?
Intellij Idea 9/10, what folders to check into (or not check into) source control?
Should the .idea folder be kept under source control?
But I suggest to check the official FAQ on this matter.
All the settings files in the .idea directory should be put under
version control except the workspace.xml, which stores your local
preferences. The workspace.xml file should be marked as ignored by
VCS.
-PyCharm 2017.3 project documentation
To explain further, workspace.xml contains user-specific workspace preferences. This includes environment variables, recently accessed files, and cursor position.
While sharing your project settings isn't inherently a bad idea, there are several exceptions and potential issues you should be aware of.
The workspace.xml file contains various user-specific settings, such as environment variables, cursor position, and Python SDK location.
Environmental variables may include private data, such as usernames and passwords
The dictionaries folder contains custom spellings, which can cause conflicts if two developers have the same name.
The .idea folder is PyCharm specific, meaning developers using a different IDE can lead to project desynchronization.
IntelliJ's own documentation includes several warnings for specific files that shouldn't be shared.
If you do decide to share .idea, IntelliJ's official documentation gives the following advice
[The .idea] format is used by all the recent IDE versions by default.
Here is what you need to share:
All the files under .idea directory in the project root except the workspace.xml and tasks.xml files which store user specific settings
All the .iml module files that can be located in different module directories (applies to IntelliJ IDEA)
Be careful about sharing the following:
Android artifacts that produce a signed build (will contain keystore passwords)
In IDEA 13 and earlier dataSources.ids, datasources.xml can contain database passwords. IDEA 14 solves this problem.
You may consider not to share the following:
.iml files for the Gradle or Maven based projects, since these files will be generated on import
gradle.xml file, see this discussion
user dictionaries folder (to avoid conflicts if other developer has the same name)
XML files under .idea/libraries in case they are generated from Gradle or Maven project
Source: JetBrains - How to manage projects under Version Control Systems
I found some issue when include whole .idea/ directory into project.
If you push to git repo including .idea/ directory, and clone that project on other machine with pycharm, pycharm can't recognize the project appropriately.
After delete .idea/ directory, pycharm recognize the project well.
The .idea/ folder is just the way that JetBrain's stores data. It's in IntelliJ and PyCharm, so, yes, it can be ignored.
An opensource project currently uses CMake to generate project files for multiple versions of Visual Studio.
I noticed that Node uses python script to do a similar thing but is more elegant since the output of the tool doesn't hardcode directory paths into those project files. However the current node setup only seems to support 2010 and 2012. The node documentation doesn't say what the build tools are just "The build tools distributed with Node run on python."
The batch file included with Node calls python configure, but doing a search on that returns a zillion unrelated results.
I was wondering if this tool/script is
an open source project with website, documentation, etc.
extensible to earlier versions of VS (2003 onwards).
What I am looking to do is produce a bunch of solutions and projects that should just work straight out the box and not be tied to a particular dev's directory layout like CMake does. Also the script allows me to easily update multiple scripts if a file gets added or removed.
It turns out Node uses GYP to generate it's project files. I had a quick play earlier and seems fairly easy to use.