[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing
On 29Aug2019 0152, Armen Michaeli wrote: The installer dialog mentions Python will be installed in something like $USERPROFILE\AppData\Local\Programs\Python\Python37-32 while at the same time suggesting it will be made available for all users through the "Install launcher for all users (recommended)". This is confusing -- if the package is to be made available for everybody, it shouldn't be installed somewhere under the profile folder of whomever is installing it, normally other people can't even access this folder at all. It should be installed in %Program Files(x86)%, unless it is a private installation indeed (the "Install launcher for all users" is unchecked). Is this an omission of sorts? Is one expected to correct this themselves, during installation -- I don't see where one would even specify the installation folder? The launcher is installed separately from the main Python installation. So everyone will have access to the launcher, but only you will have access to the Python install - if someone else on the machine installs Python as well, they won't have to install the launcher. It also means that regular users can install packages without needing to be admin, and without corrupting other user's installs. The settings you are looking for are under the second big button that says "Customize installation // Choose location". This is the second query like this I've had (well, forever, really) in the last couple of months, and my inclination is to make the launcher a per-user install by default. The main reason for making it as a per-machine install by default was because there was no other way to replace the Python 3.4 launcher, but I suspect that's less of an issue now. (If the old one wasn't replaced, it would take precedence over the new per-user one and wouldn't be able to find some newer versions of Python.) If that checkbox were not present on the front page of the installer and everything was only installed for you, would you still have raised this question? I'm trying to see if that would be a satisfactory fix. Cheers, Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NVESDIQPQA6GQUE5L7R6ROAUR444WTKV/
[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing
29.08.19 18:35, Steve Dower пише: The main reason for making it as a per-machine install by default was because there was no other way to replace the Python 3.4 launcher, but I suspect that's less of an issue now. (If the old one wasn't replaced, it would take precedence over the new per-user one and wouldn't be able to find some newer versions of Python.) Would not be an issue with replacing the globally installed Python 3.7 launcher? If that checkbox were not present on the front page of the installer and everything was only installed for you, would you still have raised this question? I'm trying to see if that would be a satisfactory fix. What if place options for the Python interpreter and the Python launcher on separate pages? They are different programs which can be deinstalled independently. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/D7LPCXOTZENP4RYUQ3PA3TQIFDF2BX27/
[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing
On 29Aug2019 0851, Serhiy Storchaka wrote: 29.08.19 18:35, Steve Dower пише: The main reason for making it as a per-machine install by default was because there was no other way to replace the Python 3.4 launcher, but I suspect that's less of an issue now. (If the old one wasn't replaced, it would take precedence over the new per-user one and wouldn't be able to find some newer versions of Python.) Would not be an issue with replacing the globally installed Python 3.7 launcher? No, since 3.5 the launcher has been installed with a consistent ID, which means there is only ever one registered installation. Prior to that, the ID was randomly generated for each installer build, so most of the time you'd have multiple registered installs that just stomped on each other's files (and uninstalling one would delete the file, rather than refcounting it properly). I'd have to test the upgrade step though - upgrading from a per-machine install to a per-user install will probably remove the per-machine one, though we should be able to detect the per-machine one and default to keeping it. This is the messiest part of installation... If that checkbox were not present on the front page of the installer and everything was only installed for you, would you still have raised this question? I'm trying to see if that would be a satisfactory fix. What if place options for the Python interpreter and the Python launcher on separate pages? They are different programs which can be deinstalled independently. They already are on separate pages :) But the "Install now" button doesn't go to the next page, it jumps straight into laying down files, and since this one checkbox is the difference between needing admin or not (and if <=3.4 is installed, the launcher working or not), it made sense to promote it to the front page. As that last point may not be so important anymore, it might be time to remove it and simplify things further. Cheers, Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EKXYOENMYZRQJ6WUMRKW7I7H3FEBYBMZ/
[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing
On 8/29/2019 4:52 AM, Armen Michaeli wrote: Hi all, The installer dialog mentions Python will be installed in something like $USERPROFILE\AppData\Local\Programs\Python\Python37-32 while at the same time suggesting it will be made available for all users through the "Install launcher for all users (recommended)". This is confusing -- if the package is to be made available for everybody, it shouldn't be installed somewhere under the profile folder of whomever is installing it, normally other people can't even access this folder at all. It should be installed in %Program Files(x86)%, unless it is a private installation indeed (the "Install launcher for all users" is unchecked). Is this an omission of sorts? Is one expected to correct this themselves, during installation -- I don't see where one would even specify the installation folder? Armen, do you understand that the py.exe launcher is a separate program from 3.7 python.exe and that it is a *multiversion* launcher and that only one copy of the program is needed on the system regardless of how many users have how many pythons installed and that it is best if the one copy is the latest possible version? -- Terry Jan Reedy ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AMJTU5Z6QCCJAEUTHELSEFXJUVBZX2UA/
[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing
On 8/29/2019 11:35 AM, Steve Dower wrote: The launcher is installed separately from the main Python installation. So everyone will have access to the launcher, but only you will have access to the Python install - if someone else on the machine installs Python as well, they won't have to install the launcher. It also means that regular users can install packages without needing to be admin, and without corrupting other user's installs. I find the layout confusing as it is and suspect that people do not really cognize 'launcher' properly. The layout starts with the specific python to be installed, offers to install it with defaults, jumps to the launcher, which newcomers likely will not understand, and jumps back to offering the one customization for the specific python that does not require hitting the customization button, and which I believe is not available if one does. I believe that that launcher is not installed if it would be a downgrade. I do not understand the shield versus arrow icons. What I recommend: Install Python 3.x [Install now] with listed defaults, including no path. [ ] Add 3.x to path # this should be in the python install blue [Customize other features] of the installed python. --- # Some definite separation and distinction from python.exe install "This installer also installs the multiversion py.exe launcher if doing so would not be a downgrade. If you have admin access, we recommend installing one py.exe for all users. See xxx for how to use py.exe. [ ] Install py.exe for all users. -- Terry Jan Reedy ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SRVWD2Q45JKAJDLSW5YIPLWD2OKGKYCP/
[Python-Dev] Re: [python-committers] PEP 581/588 RFC: Collecting feedback about GitHub Issues
> On Aug 27, 2019, at 10:44 AM, Mariatta wrote: > > (cross posting to python-committers, python-dev, core-workflow) > > PEP 581: Using GitHub Issues has been accepted by the steering council, but > PEP 588: GitHub Issues Migration plan is still in progress. > > I'd like to hear from core developers as well as heavy b.p.o users, the > following: > > • what features do they find lacking from GitHub issues, or > • what are the things you can do in b.p.o but not in GitHub, or > • Other workflow that will be blocked if we were to switch to GitHub > today > By understanding your needs, we can be better prepared for the migration, and > we can start looking for solutions. Thanks for soliciting input and working on this. I'm a heavy BPO user (often visiting many times per day for almost two decades). Here are some things that were working well that I would miss: * We controlled the landing page, giving us - A professional, polished appearance - A prominent Python Logo - A search bar specific to the issue tracker - A link to Python Home and the Dev Guide - Hot links to Easy Issues, Issues created by You, Issues Assigned to You * The display format was terse so we could easily view the 50 most recent active issues (this is important because of the high volume of activity) See https://mail.python.org/pipermail/python-bugs-list/2019-July/date.html for an idea of the monthly volume. * The page used straight HTML anchor tags so my browser could mark which issue had been visited. This is important when handing a lot of issues which are constantly being reordered. * The input box allowed straight text input in a monospace font so it was easy to paste code snippets and traceback without incorporating markup. * Our page didn't have advertising on it. * Having a CSV download option was occasionally helpful. * BPO was well optimized for a high level of activity and high information density. * BPO existed for a very long time. It contains extensive internal links between issues. There are also a huge number of external deep links to specific messages and whatnot. Innumerable tweets, blog posts, code comments, design documents, and stack overflow questions all have deep links to the site. It would be a major bummer if these links were broken. It is my hope that they be preserved basically forever. Things that I look forward to with Github Issues: * Single sign-on * Better linkage between issues and PRs What I really don't want: * The typical Github project page prominently shows a list of files and directories before there is any description. If the CPython issues pages looks like this, it will be a big step backwards, making it look more like a weekend project than a mature professional project. It would be something I would not want to show to clients. It would not give us the desired level of control over the end-user experience. * If there are advertisements on the page that we don't control, that would be unprecedented and unwelcome. * On the one hand, we want issues to be easier to file. On the other hand, if the volume of low quality issues reports goes up, it will just add to the total labor and contribute to negativity (denying someone's request isn't fun for either the rejector or rejectee). * We need to retain control over our data so that we're free to make other migration decisions in the future. We can make a change now *because* we have the freedom. The migration needs to avoid vendor lock-in. I have high hopes for this being a successful migration but have to confess major disappointment that the steering committee approved this without talking with the heavy BPO users and without seeing what the new landing page would look like. In the end, the success of the migration depends on how the site works for the most active issue responders. If the workload goes up and becomes more awkward to do in volume, then heavy volunteer participation will necessarily decline. Perhaps a half-dozen individuals do more than half of the work on the tracker. I have high hopes for the success of the migration but success isn't a given. Raymond ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BNHMLY4YEXIG4VANOXSOGNXO5Y7OT3BO/
