Categories

Tuesday, February 11, 2014

Visual Studio as a Maya Python IDE


I already love to use Visual Studio for C++ plugin development but when it came to python tool development, Visual Studio used to lack a lot of the features that I genuinely enjoyed in Eclipse. However, thanks to Jos Balcaen, there are amazing new plugins available with Visual Studio's Python tools that allow Visual Studio to have all of the fun perks that Eclipse has as a Maya Python IDE. These plugins are available for Visual Studio 12 or higher. I'm using 12 in this picture with Maya 2014. It works really great and the workflow to connect Visual Studio to Maya is nearly identical to Eclipse. This is a really great deal especially if you're a big Visual Studio nut and want to use Intellisense or Visual Assist to debug your python tools. This is especially sleek if you're primarily using Windows and of course if you can afford a license :D.

If you have Visual Studio 12 or higher, you can set it up as a Maya Python IDE using this link:
http://josbalcaen.com/maya-python-visual-studio-2012/

Currently, I'm doing an audit between Visual Studio, Eclipse, and PyCharm to see which IDE fits best for my needs. Right now it looks like if you only care about python development, just use PyCharm. It's a really excellent Python IDE in general, arguably better than the other two for Python development. If you want a full fledged multi-language IDE to develop Python and C++ tools for Maya or what not and you only use Windows, go with Visual Studio. If you need something FREE, open source, cross platform (Windows, Linux, Mac), and multi-language and you're willing to put in a little bit of extra effort, go with Eclipse for sure.

Hope this information is useful. Let me know if there is any other IDE out there that can give these options a run for their money and I will research that as well!


5 comments :

  1. Hi!

    I'm a developer working on PTVS, and I'm really glad to hear that you found it useful in your work.

    You've mentioned that you're doing a more in-depth comparison of Python IDEs. Will you share the results of that once you're done? As a team, we are always interested in knowing what we can do better to make the users happier about our product, especially so in areas where it is lagging behind competitors.

    Of course, we know about quite a few things that e.g. PyCharm does better than PTVS (and others that PTVS does better than PyCharm), but it is so much more valuable to know what _you_, as a user of both products in real-world scenarios and applications, find important and useful - the things that make you conclude that PyCharm is a better general-purpose Python IDE.

    ReplyDelete
  2. I am absolutely stoked that I can give you feedback for PTVS!

    Maybe it's already available but I failed to find a few things with PTVS that's kind of already built into Eclipse and PyCharm.

    Here's a few things that I wish I could get with PTVS that is in the other IDEs:

    PyCharm is incredibly good at enforcing PEP 8 coding standards. Eclipse does a decent job at it as well as PTVS but PyCharm is more explicit about when you're breaking PEP 8 or not. Eclipse has warnings set up under your code if you define unused imports or variables and if you have white space issues. It highlights mistakes or errors on the spot. I know you can do this in Visual Studio using the error list view but in other IDEs, it just works in any view. I know Visual Assist and C# in Visual Studio do this too. I just haven't been able to see this in PTVS.

    Another thing is the syntax highlighting in PTVS tends to be lacking like C++ vanilla in Visual Studio. Eclipse and PyCharm highlight just about everything you can think of and it's really easy to read your code that way. PTVS only seems to highlight definitions, imports, and comments.

    VS's C# setup is incredible with syntax highlighting and I also really like How Visual Assist handles C++ as well. If you could get PTVS to look more like the C# implementation of Visual Studio, it would be fantastic.

    Here are some things about PTVS that I love as a Maya tools developer!

    Intellisense!!! Enough said there but I'll still say more :P. I can use all of the great Intellisense features in Python that I could in C# and C++. Very awesome that it works all the same. I have a friend at work whose a graphics engineer who primarily works in C++ who says that the Python implementation actually does a better job finding definitions of functions and finding all methods in your solution that call your function than the other language implementations do.

    I also love just with Visual Studio in general the ability to attach to processes versus resorting to opening a serial terminal and port against a Python executable for debugging. PTVS especially since 2012 is amazing at that for Maya. Unfortunately there are issues with Motionbuilder which I also write tools for. I can attach Motionbuilder to Visual Studio and hit break points but I can't step forward or into functions once I hit a break point like I can with Maya and Houdini. With Eclipse, as long as you're running against a Python executable using the terminal port setup, it doesn't care at all what application you're working against and works all the same.

    Another thing that I love is when debugging, if I'm calling an MClass in Maya, I can get much more feedback from the arguments that get fed into those classes. From my memory working with plugins in Maya with Visual Studio in C++. When I debug and I check an instance to a C++ class in Visual Studio, I don't really see any of the arguments that get passed through. With PTVS, when calling OpenMaya for those same classes, I can see the values of the arguments getting passed through. I haven't actually tested PyCharm and Eclipse to see if they give the same kind of feedback but I at least know that PTVS will which is incredibly useful!

    This is just the stuff off the top of my head. I can give more feedback over time as I test these IDEs some more if you're interested. Again, I work in different environments and If I'm using a Linux setup, I can't exactly use Visual Studio. Also if I want to write tools that are cross language, I won't necessarily use PyCharm. Because I tend to also write in C++ and C# at work, Visual Studio is kind of a no brainer there.

    ReplyDelete
  3. Thank you for a detailed-write up - this is very helpful!


    Regarding PEP 8, PTVS didn't actually have much to help you there until very recently. 2.0 will show error squiggles for parse errors, but nothing beyond that. A long-standing feature request has been to add Pylint support (https://pytools.codeplex.com/workitem/162), which we just did for 2.1 alpha - it's still not quite the same as on the fly, as-you-edit error detection as in PyCharm, as you need to invoke it explicitly (and then you'll get entries in the Error List). We also have some ideas of rolling our own, better integrated code analysis / error reporting feature based on our existing code intelligence engine (which drives code completion and refactoring) that could not only do PEP 8, but go beyond that by e.g. warning you about potentially mistyped variable or field names. We already have a great deal of information from the code analysis that begs to be surfaced that way, so this is definitely on the radar. This is not yet scheduled for any particular release, though.


    With respect to syntax highlighting, note that this is partially because the default VS color scheme uses the same color for different token types - so while it all looks the same out of the box, it really doesn't have to. This is actually true of both C++ and Python. C++ is even more advanced in that regard, as it assigns different types to e.g. local vs global variables, static and non-static fields, function parameters etc. For Python, the distinct categories are: identifier, generic literal (used for numbers), string literal, keyword, operator - these are all shared with other languages - and then distinct categories for dot, comma and grouping constructs (braces etc), You can find these in Tools -> Options -> Environment -> Fonts and Colors.

    We have a bunch of feature requests to improve the state of affairs here for Python:
    https://pytools.codeplex.com/workitem/803
    https://pytools.codeplex.com/workitem/129
    https://pytools.codeplex.com/workitem/852
    https://pytools.codeplex.com/workitem/825
    https://pytools.codeplex.com/workitem/948
    https://pytools.codeplex.com/workitem/2013

    and a somewhat related:
    https://pytools.codeplex.com/workitem/129

    Feel free to add more for any specific distinction that you think we need to support (e.g. do you want to have locals highlighted differently?)

    ReplyDelete
  4. Regarding problems with attaching to running processes - we do actually offer a functionality similar to PyDev & PyCharm where you can explicitly set up debugger connection from inside your script. This was originally written to enable remotely debugging scripts on different platforms, but should also be usable in a scenario that you describe - have a look at the docs: https://pytools.codeplex.com/wikipage?title=Features%20Remote%20Debugging

    Having said that, if regular attach doesn't work for you, then it's something that we should look into and see if we can solve this. The way attach works is somewhat hacky (Python was never designed with this in mind), so there are cases where the application hosting the Python interpreter can do things that would break our ability to do so, but it's still worth looking into. Can you please file a bug for this in the tracker (https://pytools.codeplex.com/workitem/list/basic)?

    One other thing that may sometimes let you attach when nothing else works is using the mixed mode debugger (https://pytools.codeplex.com/wikipage?title=Features%20Mixed-mode%20Debugging). It's actually completely different from the regular Python debugger, and while having fewer features due to various limitations inherent in debugging native and Python code at the same time, its architecture makes it more tolerant to idiosyncrasies of the debugged application when attaching, to some extent (in the future, this should also make it possible to use it to debug crash dumps of Python apps). It's also something that you may find handy in general if you're writing your own Python extension modules in C++, and then using them from your Python scripts.


    We're definitely always looking for more feedback! PTVS is a very user-driven project when it comes to defining feature priorities and identifying pain points to fix. So the more details you can give, the better. This doesn't have to be just about things like straightforward bugs and feature requests, either - e.g. it would be equally valuable if you can describe your workflow with Python, and give some general broad ideas about what could be done to make it smoother, opportunities for further automation etc, or even very minor things that annoy you because of how often you run into them.

    For bug reports and feature requests, it's best to post these directly into the issue tracker (https://pytools.codeplex.com/workitem/list/basic), as that is reviewed and triaged regularly by the team, and you can subscribe to update notifications for the items there. It also lets other users vote on the items, and we do take those votes into account when prioritizing features. You might also want to take a look at some of the features already in there, especially those that have a few votes, and vote for them as well.

    For general discussions and feedback, or if you find that you need help getting something going, our forum is the best place: https://pytools.codeplex.com/discussions. The team is subscribed to that, so we can see your posts immediately and can react to them quickly. The people answering questions there are all PTVS developers; we don't have a separate support team - you implement it, you support it :)


    By the way, we just shipped (literally, it went live as I am typing this) PTVS 2.1 alpha:
    https://pytools.codeplex.com/releases/view/117511

    Obviously, the usual caveats of an alpha release do apply, and I'm not sure if you'll find many interesting additions in it for your scenario, since this release was primarily focused on web development. However, it does add Pylint integration, the ability to customize the build for Python projects, and quite a few bug fixes in all areas including debugging and code analysis, so it might still be worth giving it a try.

    ReplyDelete
  5. Thank you so much for the quick reply! I'm going to try all of these now.

    ReplyDelete