On Tue, Mar 15, 2016 at 3:35 PM, anton <anto...@gmx.de> wrote: > Hi Ryan, > > I am developping on windows where I use > - python 2.7 (with tools like django) > - C# (Visual Studio 2008) for some stuff, > - php (piwik) > - apache ( with a ntlm module to allow single sign on in out intranet) > - sometime python packages wich contain native C files > (which are compiled by my Visual Studio, > for example the apache modwsgi module) > > Now all python 3.0 - 3.4 use Visual Studio 2010 which is > no more actual, and since I bought a new version (my company) > I bought Visual Studio 2015 of course. > > Now: > - python 3.5 is based on Visual Studio 2015 > - the actual php 7 windows binaries are built with Visual Studio 2015 > - the actual http://www.apachelounge.com windows apache binaries > are built with Visual Studio 2015 ( there exist binaries built with > other Visual Studio versions but Visual Studio 2008 is *no* more > supported. > > So I would like to make the big jump directly to python 3.5, > because I am more comfortable when all my > modules are based on the same compiler so I am sure > that all (necessary) components are binary compatible. >
Are you developing Trac or Trac plugins? If not, then I think you'll be investing a lot of working in moving your Trac installation to Python 3.5 with little to gain. Alternatively, you can isolate your Trac installation with a virtual environment and this is good practice even if you don't have multiple Python installations on your system. If you aren't doing development for Trac then you'll never even notice that it's running a different Python version after the initial setup. I would recommend focusing on isolating your environments rather than keeping everything compatible in a single environment. Anyway, you don't really have another other option right now unless you want to modify Trac yourself. You could probably run a "development stable" (1) release (e.g. 1.3.1, which might be released in July or August) on Python 3.5 later this year, but you'll be taking on the burden of testing stable but unproven code. We certainly don't mind since we need users to test and report issues, but beware of the caveats (2) and make sure you are up for them before taking that step. - Ryan (1) https://trac.edgewall.org/wiki/RoadMap#MilestoneCategories (2) https://trac.edgewall.org/wiki/TracDownload#LatestDevRelease -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to trac-dev+unsubscr...@googlegroups.com. To post to this group, send email to trac-dev@googlegroups.com. Visit this group at https://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/d/optout.
