This project has moved and is read-only. For the latest updates, please go here.

Physical vs logical file organization

Jul 25, 2012 at 2:06 AM


First, thanks for an excellent Python development tool. I am finding it extremely problematic that adding, removing, and moving files in folders in the project also happens physically on the disk.

First, this makes a mess when the project files are under version control.

Second, by removing a file from a project I rarely mean to remove the file from the disk. Now it happens even without a choice.

Third, I am unable to include into the project the documentation files (.txt) that I keep on the same directory as the solution file (if I add them, they will copied to the wrong place, the project directory).

In my opinion the physical file organization should be completely isolated from the logical operations in the project, as is the case when you do things in C++, say.

What are your thoughts on this?



Jul 25, 2012 at 2:30 AM

Hi Kalle,

The Python project system is similar to the C# and VB.NET project systems.  If you are used to the C++ project system, it can take some time to get used to the differences.

You may not have noticed, but you can add a file as a link.  When you select Add Existing Item, click on the down arrow on the Add button and select Add as Link.  This may help alleviate some of your pain (at least for your documentation files).



Jul 25, 2012 at 12:03 PM

Hi Hugues,

Thanks for pointing out the "Add as Link" and a fast reply time. It solves the problem I presented. Some notes:

From the usability viewpoint, I had searched for such a button before, but was able to find it (I found it now). If you can control its position, then perhaps it would be better turned into a tick mark (the selection menu in the add button seems non-standard to me) in the "Add existing item" window. In addition, I was hoping that there was a way to make the add-as-link as the default action (the tick mark could simply preserve its settings).

The problem of adding folders "as links" still persists. The idea would be to be able to do logical grouping inside a project, although physically the files are in the same directory.


Jul 25, 2012 at 4:26 PM

The "Add as Link" feature belongs to Visual Studio (it also works in C# and VB), so unfortunately we don't have any control over its placement. The menu in the open dialog shows up in a few places, but it is not very common. I haven't checked, but VS 2012 may have made some changes to this command as part of their UI redesign.

There are basically three ways to represent a project: fully physical (equivalent to Show All Files), fully logical (what C++ has) and a hybrid (what we have right now). We already have huge demand to support the fully physical representation, since that is how Python interpreters handle packages, but that suffers from showing too many files (such as *.pyc). Our current system allows you to include or exclude any individual file, but it will ensure that the project hierarchy matches what the Python interpreter sees, which is the physical locations.

A purely logical view would cause havoc for many Python developers - "I moved from folder B to folder C, but 'import C.A' doesn't work?" This feature would be really hard for us to justify.

Another potential solution for your specific problem may be Solution items, another VS feature that is not easily discoverable. (Short story: you can add your documentation files to the solution rather than the project.)

Jul 26, 2012 at 1:40 AM

Thanks for the reply. I can live with the linked files:) The solution items (at least the solution folders) aren't available in Express versions of Visual Studio, which hinders their use quite a bit. I am unable to see how the physical model could ever work together with an external version control (such as Mercurial). For example, moving a file makes the version control think the file is missing. How do the Python (or C# or VB) developers deal with this issue?

Jul 26, 2012 at 4:23 PM
Edited Jul 26, 2012 at 4:23 PM

If you are using the integrated source control functionality of VS then it handles moves or renames in the project. This is built-in for TFS and there are extensions for SVN and Mercurial (and more, go to and search for what you're interested in). Express editions don't support integrated source control, but it's possible that the Integrated Shell does, which is what you'll be using if you don't have VS Professional or higher.

Without integrated support in VS it is a little more complicated. My personal approach with TortoiseSVN was to exclude the file from the project, rename it through Explorer and add it back. TortoiseHg has a 'guess renames' feature that works quite nicely as long as you don't change the file contents too much, and also allows you to mark a missing file as renamed before you commit.

It's not ideal, but all we could really do about it is prevent moving and renaming files from VS. We're not going to do that :)

Jul 26, 2012 at 4:41 PM

I see. The version control has to be integrated into the Visual Studio to work nicely with the physical model. As a result of this discussion I found the VisualHg which works very well together with the TortoiseHg and Visual Studio. This is a welcome find also to my C++ projects, especially in easeing moves and renames. Thanks Zooba and huguesv for your time.