Steve Dower added the comment: > miniconda does not install all of the sci-data packages, only conda and > python 2.7
miniconda is actually a tool that gives you the "conda" command, which can be used to install Python 2.6, 2.7, 3.3 or 3.4, 32 or 64-bit and a huge range of compatible packages. When you install it you also get a usable version of Python, but you don't have to use it. Anaconda is exactly the same thing but with a selection of packages predownloaded and installed - again, you can use the conda command to install more. > What is Microsoft's official position on python. are they officially > supporting python on windows? Microsoft doesn't distribute Python as part of Windows or provide any support for users, though we do provide some engineering support (i.e. me) and some low-cost efforts (such as the compiler pack, again, mostly me). There's a really high bar for "supporting" a product, and especially for shipping it to users who have not opted into it, as well as legitimate concerns about documentation/support, entry points, threat vectors, updates, patching, and probably more (when does Windows switch to 3.6? Honestly, it can probably never happen...). While it may happen eventually, I think we're better off having an installer that any sysadmin can use to make it as-if it were shipped. The problem with that is then you can't use that installer for your app, for the same reason that a Linux application can't arbitrarily replace the system Python. You can't even ask your users to install it, since they may not have permissions (ignoring the CRT update issue for now - that will be resolved in time). This is where we need a way for a user to install Python-as-an-app (one install-per version-per-user) and also for an installer to include Python-as-a-library (one install-per app). It may just be that we need three separate installers: * EXE launcher for Python-as-an-app installations * single MSI with no UI for as-if-shipped installations * Merge module or ZIP file for Python-as-a-library installations (also note that the third option really needs changes/fixes to pythonXY.dll to work well) If we went this way, I'd really want the EXE launcher to be the only one with a 'friendly' UI - the other two are specifically for people who know how to read documentation and know why they're getting them (especially since I assume I'd be the one writing it all). The EXE launcher could fairly trivially trigger or acquire either of the other two, so it could still be the main entry point, but I would seriously want to demote anything other than the per-user install. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22516> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
