Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Thu, Aug 12, 2010 at 7:00 AM, Russell E. Owen wrote: ... > > If the files are shared among all users then /usr/local/ > seems more reasonable. > > I also think whatever you choose for linux is also the best choice for > Mac OS X (my preferred platform). While there are other possible > directories, such as ~/Library/Application Support/, all > tools derived from unix that I know about use the unix convention (ssh, > X11, bash...) and I would argue that Python is close enough to count > even though it is a framework build. Put another way, copying the unix > convention is simple, is exactly what power users would expect and I > don't see it would do any harm. Choosing an arbitrary location we think is good on every system is fine and non risky I think, as long as Python let the various distribution change those paths though configuration. In fact, that's one of the future goal of the sysconfig module I had in mind. Instead of having it reading paths from python variables, I would like to introduce a configuration file global to Python containing all the installation paths, and the paths we are currently discussing. That file could then be changed by distributions depending on their layouts. It will avoid distributions to hack Python to change those paths. For instance, Ubuntu currently patches distutils to change the installation paths. So let's: - define all the default locations for each system - define a sysconfig.cfg file that contains all installation paths, for each target system - change sysconfig.py so it uses it, instead of the global dicts it currently has Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden wrote: > > "David Cournapeau": >> Autotools only help for posix-like platforms. They are certainly a big >> hindrance on windows platform in general, > > That is why mingw has MSYS. I know of MSYS, but it is not very pleasant to use, if only because it is extremely slow. When I need to build things for windows, I much prefer cross compiling to using MSYS. I also think that cross compilation is more useful than native mingw build alone - there are patches for cross compilation, but I don't know their current status, cheers, David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 11/08/2010 16:22, Éric Araujo wrote: It would be nice to define one standard location for config files used by stdlib modules, and maybe also by third-party programs related closely to Python development (testing tools, static code checkers and the like), in a way that doesn’t clutter the user home directory with a dozen dotfiles while still being easily found. (The Unix notions of dotfiles and home directory have to be adapted to use non-dotfiles in some standard place on various Windows. The Mac experts disagree on the right directory to use.) The canonical place on Windows (per Microsoft [1]) is: for roaming data: the Application Data folder (exposed as the APPDATA env var and as CSIDL_APPDATA pre-Vista and the FOLDERID_RoamingAppData Known Folder on Vista+). for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA or FOLDERID_LocalAppData) The obvious difference is whether a user expects the data to be available for the same account on a different computer. At present, the user site packages are held under %APPDATA%\Python\Pythonxx, ie are considered roaming. Unfortunately, the canonical place is not always the place most used. Especially since the convention under *nix is to place dotfile or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so various locations are considered $HOME, including (but not limited to): * the directory pointed to by %HOME% * the directory pointed to by %USERPROFILE% * the "My Documents" shell folder (often, but not always, %USERPROFILE%\My Documents) * c:\ (no: really) * the NT profile home directory (typically a mapped share) Dotfiles are possible on Windows; the issue is that they can't be created within the shell (ie within Windows Explorer). They can be renamed, edited, etc without issue, so it's not much of a problem. They can be created by any program which can call CreateFile -- including Python, obviously. TJG [1] http://support.microsoft.com/kb/310294 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 8/12/2010 5:50 AM, Tim Golden wrote: > On 11/08/2010 16:22, Éric Araujo wrote: >> It would be nice to define one standard location for config files used >> by stdlib modules, and maybe also by third-party programs related >> closely to Python development (testing tools, static code checkers and >> the like), in a way that doesn’t clutter the user home directory with a >> dozen dotfiles while still being easily found. >> >> (The Unix notions of dotfiles and home directory have to be adapted to >> use non-dotfiles in some standard place on various Windows. The Mac >> experts disagree on the right directory to use.) > > The canonical place on Windows (per Microsoft [1]) is: > > for roaming data: the Application Data folder (exposed as the > APPDATA env var and as CSIDL_APPDATA pre-Vista and the > FOLDERID_RoamingAppData Known Folder on Vista+). > > for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA > or FOLDERID_LocalAppData) > > The obvious difference is whether a user expects the data to be > available for the same account on a different computer. At present, > the user site packages are held under %APPDATA%\Python\Pythonxx, > ie are considered roaming. > > Unfortunately, the canonical place is not always the place most > used. Especially since the convention under *nix is to place dotfile > or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so > various locations are considered $HOME, including (but not limited > to): > > * the directory pointed to by %HOME% > * the directory pointed to by %USERPROFILE% > * the "My Documents" shell folder > (often, but not always, %USERPROFILE%\My Documents) > * c:\ (no: really) > * the NT profile home directory (typically a mapped share) > > Dotfiles are possible on Windows; the issue is that they can't > be created within the shell (ie within Windows Explorer). They > can be renamed, edited, etc without issue, so it's not much of > a problem. They can be created by any program which can call > CreateFile -- including Python, obviously. > > TJG > > [1] http://support.microsoft.com/kb/310294 Didn't we have this discussion when per-user libraries came up? Shouldn't we be using a subdirectory of that location? We ruin the risk of Python becoming distributed so finely it becomes impossible to change things, what with per-user libraries, per-version shared binaries, per-user-per-version library configuration files and the rest. One might make a case that all configuration data should be stored in a single SQLite database (with a suitable API to hide the relational nature of the store). Then at least there would only be one file no matter how many versions of Python were installed. Seriously. We are already spending enough time doing stat calls on non-existent directories. regards Steve PS: Then we can start putting the libraries themselves in the database. That works really well. -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 11:18, Steve Holden wrote: On 8/12/2010 5:50 AM, Tim Golden wrote: [... snip explanation of standard & non-standard locations ...] Didn't we have this discussion when per-user libraries came up? Shouldn't we be using a subdirectory of that location? Yes we should. My explanation above was really just painting the picture. It should have been an Appendix for the Truly Interested. One might make a case that all configuration data should be stored in a single SQLite database (with a suitable API to hide the relational nature of the store). Then at least there would only be one file no matter how many versions of Python were installed. Seriously. We are already spending enough time doing stat calls on non-existent directories. -1 on this. I don't care how many stats we're doing; I want to be able to see my configuration / libraries etc without firing up a sqlite session. TJG ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 10:50, Tim Golden wrote: Unfortunately, the canonical place is not always the place most used. Especially since the convention under *nix is to place dotfile or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so various locations are considered $HOME, including (but not limited to): * the directory pointed to by %HOME% * the directory pointed to by %USERPROFILE% * the "My Documents" shell folder (often, but not always, %USERPROFILE%\My Documents) * c:\ (no: really) * the NT profile home directory (typically a mapped share) Additionally, on Windows Python expands ~ to the first of: %HOME% %USERPROFILE% %HOMEDRIVE%\%HOMEPATH% all of which are perfectly defensible defintions of "Home" on Windows. But combining that with the Unix-minded concept of "create a dotfile called ~/.myapp" means you get dotapps in non-standard places on Windows. TJG ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 11:18, Steve Holden wrote: On 8/12/2010 5:50 AM, Tim Golden wrote: On 11/08/2010 16:22, Éric Araujo wrote: It would be nice to define one standard location for config files used by stdlib modules, and maybe also by third-party programs related closely to Python development (testing tools, static code checkers and the like), in a way that doesn’t clutter the user home directory with a dozen dotfiles while still being easily found. (The Unix notions of dotfiles and home directory have to be adapted to use non-dotfiles in some standard place on various Windows. The Mac experts disagree on the right directory to use.) The canonical place on Windows (per Microsoft [1]) is: for roaming data: the Application Data folder (exposed as the APPDATA env var and as CSIDL_APPDATA pre-Vista and the FOLDERID_RoamingAppData Known Folder on Vista+). for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA or FOLDERID_LocalAppData) The obvious difference is whether a user expects the data to be available for the same account on a different computer. At present, the user site packages are held under %APPDATA%\Python\Pythonxx, ie are considered roaming. Unfortunately, the canonical place is not always the place most used. Especially since the convention under *nix is to place dotfile or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so various locations are considered $HOME, including (but not limited to): * the directory pointed to by %HOME% * the directory pointed to by %USERPROFILE% * the "My Documents" shell folder (often, but not always, %USERPROFILE%\My Documents) * c:\ (no: really) * the NT profile home directory (typically a mapped share) Dotfiles are possible on Windows; the issue is that they can't be created within the shell (ie within Windows Explorer). They can be renamed, edited, etc without issue, so it's not much of a problem. They can be created by any program which can call CreateFile -- including Python, obviously. TJG [1] http://support.microsoft.com/kb/310294 Didn't we have this discussion when per-user libraries came up? Shouldn't we be using a subdirectory of that location? We ruin the risk of Python becoming distributed so finely it becomes impossible to change things, what with per-user libraries, per-version shared binaries, per-user-per-version library configuration files and the rest. User editable configuration files are very different from libraries. The per user site-packages folder *should* be hidden somewhere out of the way where you can get at them if you want them but won't stumble across them all the time. e.g. AppData on Windows. For files we expect the user to be able to edit we shouldn't go out of our way to make them hard or inconvenient to find. One might make a case that all configuration data should be stored in a single SQLite database (with a suitable API to hide the relational nature of the store). Yay - let's recreate the Windows registry! A binary blob only editable with special tools, we know how much users love that. Michael Then at least there would only be one file no matter how many versions of Python were installed. Seriously. We are already spending enough time doing stat calls on non-existent directories. regards Steve PS: Then we can start putting the libraries themselves in the database. That works really well. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 11:40, Michael Foord wrote: User editable configuration files are very different from libraries. The per user site-packages folder *should* be hidden somewhere out of the way where you can get at them if you want them but won't stumble across them all the time. e.g. AppData on Windows. For files we expect the user to be able to edit we shouldn't go out of our way to make them hard or inconvenient to find. This really comes down -- as with the Mac discussion last week, I think -- to the tension between standard file locations and easy-to-get-to. The difference on Windows, though, is that while on Mac it's either: Apple standard /This/That/TheOther vs Unix standard $HOME/.something on Windows it's %APPDATA%\myprog vs whatever-I-thought-of-at-the-time. APPDATA isn't actually that hard to get to on any version of Windows post 2000. (Just stick %APPDATA% into any Explorer window -- even IE, for goodness sake). Even from the command line it's not hard: notepad "%APPDATA%\python\python26\idle.ini" Ultimately, as a Windows user/developer, I'd vote for a memorable consistency, which for me would be %APPDATA%\python\... If everything's in one place, I'll just create a shortcut / hardlink / whatever to get me there when I want to change things. TJG ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 11:54, Tim Golden wrote: On 12/08/2010 11:40, Michael Foord wrote: User editable configuration files are very different from libraries. The per user site-packages folder *should* be hidden somewhere out of the way where you can get at them if you want them but won't stumble across them all the time. e.g. AppData on Windows. For files we expect the user to be able to edit we shouldn't go out of our way to make them hard or inconvenient to find. This really comes down -- as with the Mac discussion last week, I think -- to the tension between standard file locations and easy-to-get-to. The difference on Windows, though, is that while on Mac it's either: Apple standard /This/That/TheOther vs Unix standard $HOME/.something on Windows it's %APPDATA%\myprog vs whatever-I-thought-of-at-the-time. APPDATA isn't actually that hard to get to on any version of Windows post 2000. (Just stick %APPDATA% into any Explorer window -- even IE, for goodness sake). Even from the command line it's not hard: notepad "%APPDATA%\python\python26\idle.ini" Ultimately, as a Windows user/developer, I'd vote for a memorable consistency, which for me would be %APPDATA%\python\... If everything's in one place, I'll just create a shortcut / hardlink / whatever to get me there when I want to change things. How is ~/python not memorable or consistent? (And cross-platform memorability and consistency is valuable too.) Another issue is discoverability. Many users won't know about these config files unless they *see* them. Sure if you *know* where they are then editing them is easy - but how often as a user do you browse your AppData folder? (As a windows user the only times I went delving in this mysterious location was trying to diagnose obscure errors.) I'm not aware of any consistent pattern of putting *user editable* files in AppData, and I doubt this is where most users would look for them. In fact for Windows the *correct* thing to do is probably to use the registry and then provide a graphical tool for editing the values. If you're arguing for consistency why not argue for this? If we were to provide native GUI tools for editing values then the location suggested by Ronald for the Mac (which is the standard location for preferences files maintained by GUI tools) would also be the right location. All the best, Michael TJG ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Remove "unit test needed"
Hello, I would like to see “unit test needed” removed from the workflow menu in the bug tracker. The reason is that we don't do test-driven development (or, at least, most of us don't) and this stage entry is therefore useless and confusing. Saying to someone that an unit test is needed happens during the patch review - it isn't a separate stage in itself. The reason I'm asking is that I've seen some triagers bumping a lot of issues to “unit test needed” lately, and I find this annoying. What we need is patches, not unit tests per se. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 12:17, Michael Foord wrote: How is ~/python not memorable or consistent? (And cross-platform memorability and consistency is valuable too.) I was thinking outside Python rather than inside it (where ~ has no meaning on Windows) but you make a good point here. If we were just discussing Python code this would effectively be a winning point IMO. Another issue is discoverability. Many users won't know about these config files unless they *see* them. While I sympathise with this, I'm not sure how much weight one should give it in the context of this discussion. In the Unix world, if I were guessing, I would justifiably look in ~/.myapp followed perhaps by /etc/myapp. On Windows, I might go for the registry, as you mention elsewhere, and look in HKLM\Software\MyApp but for actual files I'm not sure where "discoverable" would be. re: using the Registry: To be honest, I was answering the literal question posed by Eric: where to put config files? Not the wider question: how should config data be stored? Where the answer to the latter question might be: the Registry -- much as I find it awkward to work with at times. One very definite point in its favour as regards this discussion is that Python on Windows *already* defines a key in the Registry (and has done so since v2.0 at least) and it would make some sense to place things under there. Ultimately, I don't feel very strongly about this subject. I'm more concerned that the chosen location (file or registry or whatever) be documented -- and documented from a Windows perspective as well, so you don't have to guess what "HOME" means in this context. TJG ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
>> If the files are shared among all users then /usr/local/ >> seems more reasonable. Oh, right, I forgot to think about system-wide config files. They have to be supported by another function in site. A lot of programs have similar-looking code to get a list of filenames and then process it with configparser or something else: find_config_files in Distutils, get_standard_config_files in Docutils, rcpath in Mercurial. There are different namings to support (rc, .cfg, .conf, etc.) and also config directories (for Mercurial), but it does not seem impossible to define a standard function that would benefit Python itself and other programs. > Choosing an arbitrary location we think is good on every system is fine > and non risky I think, as long as Python let the various distribution > change those paths though configuration. Don’t you have a bootstrapping problem? How do you know where to look at the sysconfig file that tells where to look at config files? > In fact, that's one of the future goal of the sysconfig module I had in mind. Seems great. > So let's: > > - define all the default locations for each system > - define a sysconfig.cfg file that contains all installation paths, > for each target system > - change sysconfig.py so it uses it, instead of the global dicts it > currently has I wonder if this is so complex that a wiki page or something else would be better suited than email to iron out the proposal. Or maybe it’s time for that sysconfig.cfg PEP you planned to do. Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
Le 12/08/2010 12:18, Steve Holden a écrit : > Didn't we have this discussion when per-user libraries came up? > Shouldn't we be using a subdirectory of that location? As pointed out by Antoine, Georg, Michael and I, the PEP 370 directory for user site-packages is not the right place to put config files. > PS: Then we can start putting the libraries themselves in the database. > That works really well. I don’t know you well enough to tell if this is the final hint that you were sarcastic. Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12 August 2010 12:59, Tim Golden wrote:
> re: using the Registry: To be honest, I was answering the literal
> question posed by Eric: where to put config files? Not the wider
> question: how should config data be stored? Where the answer to
> the latter question might be: the Registry -- much as I find it
> awkward to work with at times.
>
> One very definite point in its favour as regards this discussion
> is that Python on Windows *already* defines a key in the Registry
> (and has done so since v2.0 at least) and it would make some sense
> to place things under there.
>
> Ultimately, I don't feel very strongly about this subject. I'm more
> concerned that the chosen location (file or registry or whatever) be
> documented -- and documented from a Windows perspective as well, so
> you don't have to guess what "HOME" means in this context.
One potential solution would be to use something like
os.path.expanduser("~/.python"), where os.path.expanduser has a
defined behaviour on Windows (one that could do with a little
clarification, yes I know, doc patch welcomed...), but also add an
additional option, that os.path.expanduser will first look in the
registry for the value HKLM\Software\Python\PythonCore\HOME and use
that if present. Then users could set their own interpretation, in a
Windows-standard manner.
If that would be an acceptable option, I could supply a patch to
os.path.expanduser. I will do a clarifying doc patch regardless.
Paul.
PS We could also support ~user by looking in HKEY_USERS\\Software\Python\... but that's probably YAGNI :-)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
> Ultimately, I don't feel very strongly about this subject. I'm more > concerned that the chosen location (file or registry or whatever) be > documented -- and documented from a Windows perspective as well, so > you don't have to guess what "HOME" means in this context. Rest assured that I don’t want to impose Unix concepts on Windows. My examples have used dotfiles since it’s what I know, but I did search and ask for the right thing to do on other platforms. Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Thu, Aug 12, 2010 at 6:18 AM, Steve Holden wrote: > Didn't we have this discussion when per-user libraries came up? > Shouldn't we be using a subdirectory of that location? We ruin the risk > of Python becoming distributed so finely it becomes impossible to change > things, what with per-user libraries, per-version shared binaries, > per-user-per-version library configuration files and the rest. Yes, we did. That was in the context of some people's desire for a per-user site-packages directory, and the result is that we're now saddled with a per-user site-packages directory. The structure determined there was the same sort of half-way version-specific mess as so many others are: libraries are per-python-version, and scripts are installed cowboy-style (whoever got there last, wins). Perhaps user configuration belongs in ~/.local/, or ~/.local/python/ (with attendant Windows & Mac OS noises); I don't really care where it lands, because right now we just have a mess. Getting it "right" with respect to Window's "roaming" notion and how people expect to work with it is... unlikely. Picking a place is better than not, so we know where to find things. But that's all it buys us. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove "unit test needed"
On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou wrote: > > Hello, > > I would like to see “unit test needed” removed from the workflow menu in > the bug tracker. The reason is that we don't do test-driven development > (or, at least, most of us don't) and this stage entry is therefore > useless and confusing. Saying to someone that an unit test is needed > happens during the patch review - it isn't a separate stage in itself. Is that stage supposed to (at least partly) capture the idea 'reproducible test-case needed', or 'verification needed'? That would seem like a more useful notion. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
On Thu, Aug 12, 2010 at 05:38:52PM +0900, David Cournapeau wrote: > On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden wrote: > > > > "David Cournapeau": > >> Autotools only help for posix-like platforms. They are certainly a big > >> hindrance on windows platform in general, > > > > That is why mingw has MSYS. > > I know of MSYS, but it is not very pleasant to use, if only because it > is extremely slow. When I need to build things for windows, I much > prefer cross compiling to using MSYS. I also think that cross > compilation is more useful than native mingw build alone - there are > patches for cross compilation, but I don't know their current status, > > cheers, > > David My argument goes that one of the biggest differences between the GNU/Linux and the Windows way of computing is the barrier between user and programmer. In the Windows way, you are either a user or a programmer. On Linux, just by the way you can download software and run ./configure && make && make install, you are encouraged to look at the source code and by this you might in the not-so-long run start reporting bugs to mailing lists and see that there are actually people who might be able to sort out the bugs and that you might become one of them. The Windows way, you think those bugs are unavoidable and start making jokes out of a feeling of frustration and helplessness. That's where msys/mingw is supposed to come in, if only it was easier to install, so that new Programmers don't get locked in in the Microsoft compiler products and thereby the divide between the software communities gets wider and wider. Don't get me wrong, I think the python project is doing a great job in terms of cross-platform portability, but things would be easier if there was an easy combination of msys, mingw and autotools. And by the way, I think the way the big linux distros like fedora and mandrake distribute software is more similar to the windows way of computing. Gabriel ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove "unit test needed"
On Thu, Aug 12, 2010 at 9:18 AM, Mark Dickinson wrote: > On Thu, Aug 12, 2010 at 12:56 PM, Antoine Pitrou wrote: .. >> I would like to see “unit test needed” removed from the workflow menu in >> the bug tracker. .. > Is that stage supposed to (at least partly) capture the idea > 'reproducible test-case needed', or 'verification needed'? That would > seem like a more useful notion. > +1 I have two problems with “unit test needed”: 1. Similar to Antoine, I find it ambiguous whether a bug without a patch is in “unit test needed” or "patch needed" stage. 2. I much prefer a small script reproducing the bug to a regression suite patch. In most cases unit tests require too much irrelevant scaffolding to be useful in understanding or debugging the issue. I remember there was an idea somewhere to replace "patch" tag with a check-list with boxes for code, tests, and docs. I think that would be better than "unit test needed" stage. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
2010/8/12 > > On Thu, Aug 12, 2010 at 05:38:52PM +0900, David Cournapeau wrote: > > On Wed, Aug 11, 2010 at 10:21 PM, Sturla Molden > wrote: > > > > > > "David Cournapeau": > > >> Autotools only help for posix-like platforms. They are certainly a big > > >> hindrance on windows platform in general, > > > > > > That is why mingw has MSYS. > > > > I know of MSYS, but it is not very pleasant to use, if only because it > > is extremely slow. When I need to build things for windows, I much > > prefer cross compiling to using MSYS. I also think that cross > > compilation is more useful than native mingw build alone - there are > > patches for cross compilation, but I don't know their current status, > > > > cheers, > > > > David > > My argument goes that one of the biggest differences between the > GNU/Linux and the Windows way of computing is the barrier between user > and programmer. In the Windows way, you are either a user or a > programmer. On Linux, just by the way you can download software and > run ./configure && make && make install, you are encouraged to look at the > source code and by this you might in the not-so-long run start > reporting bugs to mailing lists and see that there are actually people > who might be able to sort out the bugs and that you might become one > of them. > > The Windows way, you think those bugs are unavoidable and start making > jokes out of a feeling of frustration and helplessness. > > That's where msys/mingw is supposed to come in, if only it was easier > to install, so that new Programmers don't get locked in in the > Microsoft compiler products and thereby the divide between the > software communities gets wider and wider. > > Don't get me wrong, I think the python project is doing a great job in > terms of cross-platform portability, but things would be easier if > there was an easy combination of msys, mingw and autotools. > > And by the way, I think the way the big linux distros like fedora and > mandrake distribute software is more similar to the windows way of > computing. > > Gabriel > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/cesare.di.mauro%40gmail.com > Anyway Visual Studio, even with the Express Edition, is simpler and more productive for a Windows programmer. You must suggest at least an equivalent "free" alternative to make the switch convenient. Otherwise we are talking about philosophy or religion, and nobody will change his ideas. Cesare ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove "unit test needed"
On Thu, Aug 12, 2010 at 11:02 AM, Alexander Belopolsky wrote: > I remember there was an idea somewhere to replace "patch" tag with a > check-list with boxes for code, tests, and docs. I think that would > be better than "unit test needed" stage. Are you suggesting check boxes for what's needed, or for what's present? Boxes indicating the needs would probably be most useful. These should probably all be set by default on new issues. Using keywords would be acceptable, I think. Similar to "needs review". -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove "unit test needed"
On Thu, Aug 12, 2010 at 1:31 PM, Fred Drake wrote: > On Thu, Aug 12, 2010 at 11:02 AM, Alexander Belopolsky > wrote: >> I remember there was an idea somewhere to replace "patch" tag with a >> check-list with boxes for code, tests, and docs. I think that would >> be better than "unit test needed" stage. > > Are you suggesting check boxes for what's needed, or for what's present? > Please see http://wiki.python.org/moin/DesiredTrackerFeatures . Ezio, thanks for the link. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove "unit test needed"
On Thu, 12 Aug 2010 11:02:29 -0400 Alexander Belopolsky wrote: > > I remember there was an idea somewhere to replace "patch" tag with a > check-list with boxes for code, tests, and docs. I think that would > be better than "unit test needed" stage. To me the simpler the better. If there's a patch then it's the reviewer's task to point out what's missing - and that's context-dependent: some fixes don't need a doc change or a test case (or, at least, they can do without). The rationale is that the more complex a system is, the less likely we are to use it. Our current "keywords" are severely under-used. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On 12/08/2010 08:26, Tarek Ziadé wrote: [snip...] Choosing an arbitrary location we think is good on every system is fine and non risky I think, as long as Python let the various distribution change those paths though configuration. In fact, that's one of the future goal of the sysconfig module I had in mind. Instead of having it reading paths from python variables, I would like to introduce a configuration file global to Python containing all the installation paths, and the paths we are currently discussing. That file could then be changed by distributions depending on their layouts. Yes - this sounds good. +1 It also provides a single place for users who are unhappy with the defaults that we choose. Michael It will avoid distributions to hack Python to change those paths. For instance, Ubuntu currently patches distutils to change the installation paths. So let's: - define all the default locations for each system - define a sysconfig.cfg file that contains all installation paths, for each target system - change sysconfig.py so it uses it, instead of the global dicts it currently has Regards Tarek -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove "unit test needed"
On 12/08/2010 12:56, Antoine Pitrou wrote: Hello, I would like to see “unit test needed” removed from the workflow menu in the bug tracker. The reason is that we don't do test-driven development (or, at least, most of us don't) and this stage entry is therefore useless and confusing. Saying to someone that an unit test is needed happens during the patch review - it isn't a separate stage in itself. The reason I'm asking is that I've seen some triagers bumping a lot of issues to “unit test needed” lately, and I find this annoying. What we need is patches, not unit tests per se. I often see patches without a test, and have assumed this is what this stage is for - where a patch is provided without a corresponding test. On the other hand checkboxes for fix / test / docs sounds fine. Michael Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
2010/8/12 Éric Araujo : >> Choosing an arbitrary location we think is good on every system is fine >> and non risky I think, as long as Python let the various distribution >> change those paths though configuration. > > Don’t you have a bootstrapping problem? How do you know where to look at > the sysconfig file that tells where to look at config files? Personally, I'm not clear on what a separate syconfig.cfg file offers over clearly separating the directory configuration settings and continuing to have distributions patch sysconfig.py directly. The bootstrapping problem (which would encourage classifying synconfig.cfg as source code and placing it alongside syscongig.py) is a major part of that point of view. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
> My argument goes that one of the biggest differences between the > GNU/Linux and the Windows way of computing is the barrier between user > and programmer. In the Windows way, you are either a user or a > programmer. Such arguments are off-topic for python-dev; please use one of the Linux advocacy forums. A little bit on-topic, I think that Python actually helps to lower the barrier between users and programmers on Windows. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Aug 12, 2010, at 6:30 AM, Tim Golden wrote: > I don't care how many stats we're doing You might not, but I certainly do. And I can guarantee you that the authors of command-line tools that have to start up in under ten seconds, for example 'bzr', care too. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Thu, 12 Aug 2010 18:14:44 -0400 Glyph Lefkowitz wrote: > > On Aug 12, 2010, at 6:30 AM, Tim Golden wrote: > > > I don't care how many stats we're doing > > You might not, but I certainly do. And I can guarantee you that the > authors of command-line tools that have to start up in under ten > seconds, for example 'bzr', care too. The idea that import time is dominated by stat() calls sounds rather undemonstrated (and unlikely) to me. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.2 alpha 1
> ... Highlights are: > > * numerous improvements to the unittest module > * PEP 3147, support for .pyc repository directories > * an overhauled GIL implementation that reduces contention > * many consistency and behavior fixes for numeric operations > * countless fixes regarding string/unicode issues; among them full > support for a bytes environment (filenames, environment variables) > * a sysconfig module to access configuration information > * a pure-Python implementation of the datetime module > * additions to the shutil module, among them archive file support > * improvements to pdb, the Python debugger Hey, Python 3(.2) becomes more sexy than Python 2(.7)! -- Victor Stinner http://www.haypocalc.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
Cesare Di Mauro wrote: You must suggest at least an equivalent "free" alternative to make the switch convenient. Otherwise we are talking about philosophy or religion, and nobody will change his ideas. I think the point is that *because* people don't want to change their ideas, it would be good to have a mingw-based alternative. Otherwise everyone is forced to convert to the Windows religion. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
On 13/08/2010 00:44, Greg Ewing wrote: Cesare Di Mauro wrote: You must suggest at least an equivalent "free" alternative to make the switch convenient. Otherwise we are talking about philosophy or religion, and nobody will change his ideas. I think the point is that *because* people don't want to change their ideas, it would be good to have a mingw-based alternative. Otherwise everyone is forced to convert to the Windows religion. You mean people using Windows are forced to use Windows? Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Thu, 12 Aug 2010 08:18:27 pm Steve Holden wrote: > One might make a case that all configuration data should be stored in > a single SQLite database (with a suitable API to hide the relational > nature of the store). -1 Please don't even *consider* such a thing. Haven't we learned from Firefox? I for one am getting heartily sick and tired of having to "fix" (that is, throw away) corrupted Firefox databases. Please don't go down that path. -- Steven D'Aprano ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Fri, Aug 13, 2010 at 07:48:22AM +1000, Nick Coghlan wrote:
> 2010/8/12 Éric Araujo :
> >> Choosing an arbitrary location we think is good on every system is fine
> >> and non risky I think, as long as Python let the various distribution
> >> change those paths though configuration.
> >
> > Don’t you have a bootstrapping problem? How do you know where to look at
> > the sysconfig file that tells where to look at config files?
I'd hardcode a list of locations.
[os.path.join(os.path.dirname(__file__), 'sysconfig.cfg'),
os.path.join('/etc', 'sysconfig.cfg')]
The distributor has a limited choice of options on where to look.
A good alternative would be to make the config file overridable. That way
you can have sysconfig.cfg next to sysconfig.py or in a known config
directory relative to the python stdlib install but also let the
distributions and individual sites override the defaults by making changes
to /etc/python3/sysconfig.cfg for instance.
>
> Personally, I'm not clear on what a separate syconfig.cfg file offers
> over clearly separating the directory configuration settings and
> continuing to have distributions patch sysconfig.py directly. The
> bootstrapping problem (which would encourage classifying synconfig.cfg
> as source code and placing it alongside syscongig.py) is a major part
> of that point of view.
>
Here's some advantages but some of them are of dubious worth:
* Allows users/site-administrators to change paths and not have packaging
systems overwrite the changes.
* Makes it conceptually cleaner to make this overridable via user defined
config files since it's now a matter of parsing several config files
instead of having a hardcoded value in the file and overridable values
outside of it.
* Allows sites to add additional paths to the config file.
* Makes it clear to distributions that the values in the config file are
available for making changes to rather than having to look for it in code
and not know the difference between thaat or say, the encoding parameter
in python2.
* Documents the format to use for overriding the paths if individual sites
can override the defaults that are shipped in the system version of
python.
-Toshio
pgpBEZ2XsDBy9.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
> A good alternative would be to make the config file overridable. That way > you can have sysconfig.cfg next to sysconfig.py or in a known config > directory relative to the python stdlib install but also let the > distributions and individual sites override the defaults by making changes > to /etc/python3/sysconfig.cfg for instance. Putting configuration files next to source code does not agree with the FHS. Your message gave me an idea though: Some function could be called in sitecustomize (symlinked from /etc on Debian e.g.) to set the path to sysconfig.cfg. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
On 12 August 2010 20:37, Michael Foord wrote: > On 13/08/2010 00:44, Greg Ewing wrote: >> >> Cesare Di Mauro wrote: >> >>> You must suggest at least an equivalent "free" alternative to make the >>> switch convenient. >>> >>> Otherwise we are talking about philosophy or religion, and nobody will >>> change his ideas. >> >> I think the point is that *because* people don't want to change >> their ideas, it would be good to have a mingw-based alternative. >> Otherwise everyone is forced to convert to the Windows religion. >> > You mean people using Windows are forced to use Windows? > I would say people that want to support Windows but are not using it. -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
Antoine Pitrou wrote: > On Thu, 12 Aug 2010 18:14:44 -0400 > Glyph Lefkowitz wrote: > > > > On Aug 12, 2010, at 6:30 AM, Tim Golden wrote: > > > > > I don't care how many stats we're doing > > > > You might not, but I certainly do. And I can guarantee you that the > > authors of command-line tools that have to start up in under ten > > seconds, for example 'bzr', care too. > > The idea that import time is dominated by stat() calls sounds rather > undemonstrated (and unlikely) to me. In the case of bzr startup, the exact breakdown varies depending on a range of factors like OS and whether the relevant parts of the filesystem are in the OS cache or not (i.e. is this the first time the user has run bzr since booting?). The short answer is that the number of stat calls isn't really the problem at the moment for bzr, at least not compared to the number of *directories* Python searches, and the amount of non-trivial work done at import time by many modules. But... Your Mileage May Vary. Here's the longer answer: I think some stats about this have been posted to this list before, but some points of interest from the top of my head: * the cost of trying and failing to open foomodule.so + foo.so + foo.pyc + foo.py in a directory isn't much greater than trying to open just one on them. Once the OS has cached the directory entries for that directory subsequent lookups in that directory are fast. The experiement is fairly easy: - strace -e open,stat64 -o py.strace python -c "something..." - by hand, create a .C file that repeats all the stat and open in py.strace (it's pretty easy to munge into valid C) - and also create one with only the *successful* stat and open calls - compare them (using /proc/sys/vm/drop_caches or whatever as appropriate) * each directory probed is a significant cost, especially in the "cold boot" case. So every in sys.path, and every subdirectory of a package. * that said, Windows seems much slower than Linux on equivalent hardware, perhaps attempting to open files is intrinsically more expensive there? Certainly it's not safe to assume conclusions drawn on Linux will apply equally well on Windows, or vice versa. * modules with many class/function definitions are measurably slower than smaller modules. * module-level re.compile calls and other non-trivial operations are to be avoided, but many modules you depend on will do that. This matters so much that bzr monkey-patches the re module to make re.compile lazy. Try grepping the stdlib to see how many modules do re.compile at import time (including as default values of keyword args)! * it's death by a thousand cuts: each module import probably imports a dozen others... by far the simplest way to reduce startup time is to just import less modules. Lazy module imports (bzrlib.lazy_import or hg's demandload or whatever) help a lot, and I wish they were a builtin feature of Python. * I haven't even mentioned NFS or other network filesystems, but you can bet they change the picture significantly. -Andrew. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Fri, Aug 13, 2010 at 03:15:28AM +0200, Éric Araujo wrote:
> > A good alternative would be to make the config file overridable. That way
> > you can have sysconfig.cfg next to sysconfig.py or in a known config
> > directory relative to the python stdlib install but also let the
> > distributions and individual sites override the defaults by making changes
> > to /etc/python3/sysconfig.cfg for instance.
>
> Putting configuration files next to source code does not agree with the
> FHS.
>
That depends -- sometimes a config file is actually a data file. In
following the FHS, a linux distribtuion and system administrators want to
make sure a sysadmin never needs to modify a file outside of /etc for
configuration. However, if you had a config file that is installed with
python and not meant to be modified next to the code and the sysadmin is
able to customize python's behaviour by copying lines from that file to
a file in /etc/ that they do modify, that's perfectly fine. Where
developers often run afoul of the FHS is creating a configuration option
that does not live in a file in /etc/ (either because they think it's data
but system administrators routinely want to modify.it or because they don't
care about the FHS and just want to put everything in a single directory)
and hte system admin has no means to set that option permanently but to
modify the files outside of /etc/.
>
> Your message gave me an idea though: Some function could be called
> in sitecustomize (symlinked from /etc on Debian e.g.) to set the path to
> sysconfig.cfg.
>
I hope that you mean that the actual file lives in /etc/ and then a symlink
in the stdlib points to it. That sounds acceptable from an FHS view but
it's a bad idea. Most of the config files in /etc/ are declarative. A few
of the files in /etc/ are imperative (for instance, init scripts) and
distributions frequently debate whether these are actually config files or
files misplaced in /etc/ for historical reasons. Fedora, for instance, does
not mark initscripts as config -- all configuration of initscripts are done
by setting shell variables in a different file which is marked config.
(Files marked config in a package manager generally are treated differently
on upgrades. If the files have been modified since install, they are either
not replaced or, when replaced, a backup is made so that the system
administrator can merge their local changes.)
The problem with having imperative constructs in /etc/ is that they're much
harder (perhaps impossible) to fix up when changes have to be made at the
system packaging level. Let's say that you hard code this into the
sitecustomize.py when you ship it for the first time on Fedora:
siteconfig_cfg = '/etc/siteconfig.cfg'
The system administrator installs this package and then does some unrelated
customization for his site in the file:
if sys.version_info[:2] == '3.0':
sys.path.append('/opt/python3.0')
siteconfig_cfg = '/etc/siteconfig30.cfg'
elif sys.version_info[:2] == '3.1':
sys.path.append(os.environ['USER'] + '/opt/python3.1')
siteconfig_cfg = '/etc/siteconfig31.cfg'
elif sys.version_info[:2] == '3.2':
sys.path.append(os.environ['USER'] + '/opt/python3.2')
siteconfig_cfg = '/etc/siteconfig.cfg'
# [...] Do other strange stuff because if it's possible, someone will.
Now, when we update to python3.3 we decide to move siteconfig.cfg into
/etc/python3.3/. But, because the system admin has modified that file so
heavily, we don't update that file. This means the updated python is broken
out of the box.
If you're enamoured of symlinks, you can do this directly with the config
file instead of using sitecustomize::
/etc/python3.2/sysconfig.cfg
/usr/lib64/python3.2/sysconfig.cfg => /etc/python3.2/sysconfig.cfg
as a third alternative.
-Toshio
pgpCYTDznfbDR.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
On Fri, Aug 13, 2010 at 7:29 AM, Antoine Pitrou wrote: > On Thu, 12 Aug 2010 18:14:44 -0400 > Glyph Lefkowitz wrote: >> >> On Aug 12, 2010, at 6:30 AM, Tim Golden wrote: >> >> > I don't care how many stats we're doing >> >> You might not, but I certainly do. And I can guarantee you that the >> authors of command-line tools that have to start up in under ten >> seconds, for example 'bzr', care too. > > The idea that import time is dominated by stat() calls sounds rather > undemonstrated (and unlikely) to me. It may be, depending on what you import. I certainly have seen (and profiled) it. In my experience, stat calls and regex compilation often come at the top of the culprits for slow imports. In the case of setuptools namespace package, there was a thread on 23rd april on distutils-sig about this issue: most of the slowdown came from unneeded stat (and symlink translations). cheers, David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] mingw support?
Michael Foord writes: > > I think the point is that *because* people don't want to change > > their ideas, it would be good to have a mingw-based alternative. > > Otherwise everyone is forced to convert to the Windows religion. > You mean people using Windows are forced to use Windows? By far not all, but some are. Like me, I only use Windows when my boss holds up a pink paper and says "shall I sign this?" So far I haven't felt a need to build Python on Windows, but if I did I would strongly prefer to use a familiar (to me) build system based on the autotools and GCC. Because I haven't felt that need, I don't think MSYS/mingw support is a big deal. But apparently there are a few people whose Windows use case is characterized both by platform coercion and a desire to build Python themselves. The question is "who will support those folks?" I don't see any reason why you or Martin should support MSYS/mingw if you don't want to, but please don't put down the folks who ask for it. Just say "no, it's not worth it". Or maybe, "if you want to do the work, I might contribute some reviews." Or whatever. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing #7175: a standard location for Python config files
Michael Foord writes: > How is ~/python not memorable or consistent? (And cross-platform > memorability and consistency is valuable too.) But what does "~" mean on Windows? Inside of Python you can have a consistent definition, but that doesn't help people whose installer gets mixed signals so Python itself is in the wrong place, or who are using external tools (uninstaller, editor, application, etc) that work on or with Python. I'm not arguing for use of AppData, but at least it's easy to explain, and easy to implement, for consistency. > Another issue is discoverability. Many users won't know about these > config files unless they *see* them. OK, maybe AppData's out. > In fact for Windows the *correct* thing to do is probably to use > the registry and then provide a graphical tool for editing the > values. If you're arguing for consistency why not argue for this? Sounds reasonable to me. Except Python's standard GUI is probably not up to Windows standards of beauty ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
