Here's my simple summary: tl;dr: I don't think the directory based projects are useful, they might even not work correctly in a bunch of places, and they'll probably be a bug farm.
I actually think the only thing I really disagree about is that there will always be lingering crashing bugs. We can certainly be evil and wrap our file change notifications in a big try/catch and swallow all the exceptions. Obviously we'd rather know what issues can happen and work on handling them now. Other than that though you do bring up some good problems with the directory based projects. In addition to swimming against the stream of VS we are also swimming against MPFProj - there we need to create an MSBuild item for each project entry - and currently we end up leaving some files in the .pyproj file even though they have no significant effect. And we even need additional code to deal with not endlessly expanding the project files! So I guess what I'm saying is there are more issues than you've enumerated. Another one is that we don't support File->New->Project from Existing Code which also helps eliminate the need for directory based projects. I actually don't have a huge attachment to this feature - we thought that it would be a more comfortable fit for Python programmers. But if there's a feeling that the feature isn't working then I'd be alright with going w/ the more traditional VS model. We still would want to have a support for a projectless model but maybe our efforts are betters spent making that robust and accepting the normal VS experience. So if anyone thinks the directory based projects are totally awesome I'd love to hear their counter-points. > -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@lists.ironpython.com] On Behalf Of Steve Dower > Sent: Saturday, May 15, 2010 3:56 AM > To: Discussion of IronPython > Subject: [IronPython] IronPy Tools for VS - Projects > > Just thought I'd put out some more thoughts on the automatic project > hierarchy that IronPy Tools has (for now?) in the Solution Explorer. > (I'll put out there right away that I would rather see it removed and > have the traditional project management instead. Everything else I > write should be read in that context.) > > Apart from importing an existing project into VS, there are very few > other times when you want all the files at once. For imports, it's > great, but for a new project it is unnecessary since there are no > relevant files at that point. Any new .py files will probably be > created through VS, rather than being created externally in such > quantity as to make dragging and dropping from Explorer painful (and > the Add Existing Item dialog supports multiple files as well). Add to > this that Solution Explorer has for quite some time had a "Show All > Files" button and there is no reason to have it exposed all the time. > > Next is the clutter that comes with having all files visible. Run your > project with CPython (compatibility testing or for whatever reason) > and you get .pyc files appear everywhere. Run with -O and you'll get > .pyo files as well. Every one of these appears in Solution Explorer, > making the tree three times as long as it needs to be. Version control > related files or folders (such as .svn or .hg) are also visible. (I > know I've already raised this and a solution is coming, but the > necessity of another solution is still a point against.) > > Third, automatically generated files are common and can get very > messy. The obvious destination for pydoc or epydoc documentation is > within the project folder. VS automatically expands folders when new > files appear, so updating documentation turns Solution Explorer into a > list of html files. Worse, search "Current Project" for something and > all of these files are searched as well (and for some reason, are left > open even if the text is not found...). > > Fourth is not something that has affected me, but I'm not entirely > sure how source control that is integrated into VS behaves with this. > I believe that it was associated with the service providing the > project nodes, but I haven't looked into VS2010 in this area yet. > Either way, automatically including every file into source control is > probably not appropriate (and certainly is not appropriate in *every* > case). > > Finally, bugs. I haven't been able to reproduce every one I've come > across, but most relate to changing the project files via Explorer > while VS is open. Since I'm using SVN with TortoiseSVN I can't use VS > exclusively for file management, and occasionally renaming, creating > or deleting a file will cause VS to crash hard ("send error report"), > crash soft ("run with /log") or display multiple/repeated files in > Solution Explorer. > > In summary, I'd rather have the traditional style projects in IronPy > Tools (as in C#/C++/VB) because: > - I very rarely need to import an existing tree > - most project changes are adding code files, best done through VS > - there is a 'Show All Files' option for those who want it > - there are many files I don't want to see in VS > - integrated source control may(?) misbehave > - there will always be edge-cases with regards to synchronisation that > cause crashes > > I hope this is taken in the right spirit - I'm trying to be > constructive, not to criticise from the sidelines. (After spending a > while working on my own equivalent project, I'm keen to see this one > succeed.) > > Cheers, > > Steve > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
