Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
It is a surprise to find builtin msilib. Why isn't it used? Originally, because Python needs to be packaged with an older release (in particular one that isn't itself maintained anymore). Today, the problem is that the msilib package doesn't support merge modules (and if such support was added, we would have to wait until the version containing it isn't maintained anymore). I don't consider the dependency on win32com a serious issue at all; it's just a mild annoyance (much less than reliance on ctypes would be, or hard-coding of symbolic constants). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Wed, Feb 2, 2011 at 10:36 AM, Martin v. Löwis mar...@v.loewis.de wrote: It is a surprise to find builtin msilib. Why isn't it used? Originally, because Python needs to be packaged with an older release (in particular one that isn't itself maintained anymore). That doesn't answer the question why Python could not be packaged with a newer release of 'msilib' at that time? Today, the problem is that the msilib package doesn't support merge modules (and if such support was added, we would have to wait until the version containing it isn't maintained anymore). I don't understand the phrase in (). What for do we need to wait after adding support for merge modules to builtin msilib? I imagine we've added support for merge modules to msilib, and then waiting until new msilib version with merge support isn't maintained anymore. And only then we can use it to create installer. Sounds like a nonsense. Anyways, is it possible to reuse builtin msilib to the max and add required 'merge modules' functionality inside msi.py or extension module? I don't consider the dependency on win32com a serious issue at all; it's just a mild annoyance (much less than reliance on ctypes would be, or hard-coding of symbolic constants). There is nothing wrong with hardcoded symbolic constants - Microsoft specifically provides values for them in their MSDN materials to be used with scripting languages which doesn't have include files. They just need to be validated one time, and won't change in future. Why don't you like ctypes solution? I find it strange that Python build process avoids using its own modules. -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Tue, Feb 1, 2011 at 5:35 PM, anatoly techtonik techto...@gmail.com wrote: Because code cleanup patches pave road for more complex pieces of work. Clean code makes patches easier to review. It saves developer's time and as a result useful patches are integrated into codebase more quickly. While I've occasionally wished for the ability to enter clarification as the issue type (especially for docs patches), simply leaving the issue type blank when none of the available categories fits has worked well enough as an alternative. If it helps, try to think of it as this code isn't clear as it could be, which is a readability bug Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Tue, Feb 1, 2011 at 01:35, anatoly techtonik techto...@gmail.com wrote: On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson benja...@python.org wrote: I see no reason for b.p.o bureaucracy. It provides a place for discussion, and makes it easier to coordinate multiple efforts. Code review system provides a better space for discussion if we are speaking about simple code cleanup. To me polluting tracker with the issues that are neither bugs nor feature requests only makes bug triaging process and search more cumbersome. If it's not a bug or a feature request, why does it need to change? Because code cleanup patches pave road for more complex pieces of work. Clean code makes patches easier to review. It saves developer's time and as a result useful patches are integrated into codebase more quickly. -- anatoly t. Code cleanup patches, if you mean minor refactoring, are generally not where developer time is best spent. We could all come in and make 50 check-ins each of refactoring but the net benefit is even, if not negative. Yes, clean code is easier to work with, easier to review, etc., but keep in mind we're working with multiple branches that also need to be kept in sync. Refactoring some function in py3k should probably be replicated in release31-maint, and possibly release27-maint, otherwise patching between the branches becomes more time intensive. Adding time intensive work with no net gain is probably the last thing we want to do. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik techto...@gmail.com wrote: To me polluting tracker with the issues that are neither bugs nor feature requests only makes bug triaging process and search more cumbersome. Anatoly, your constant efforts to try to force python-dev to adapt to *your* way of doing things, instead of being willing to work with the documented processes are *seriously* annoying. Which is a shame, since it obscures the fact that your underlying suggestions are often quite reasonable. I'll abandon my efforts when you prove me that current documented process is a top-notch way for all interested parties to do a quality contributions to make Python better. So that the process is open, straightforward, transparent and doesn't waste people's time more than necessary to communicate a change, make it visible for all interested parties, get feedback, polish and finally integrate. There are many ways for improvement, but if people won't try alternative approaches, they won't see them. I am not sure if I can manage to get to PyCon, so I didn't do any talk preparation, but if by chance I get there and there will be an Open Space, we can definitely find a lot of ways to improve Python development process for general public. As well as discuss ways to get around stdlib graveyard and dealing with really complicated problems that won't budge over the years - like out of the box UTC support. The most valuable contributions are coming from professionals, and these people often don't have enough time to follow documented process. In the era of information abundance you often have only 140 symbols to communicate the idea, and instead of blaming people of annoying behavior, it might be more useful to make process intuitive and easy to follow. If that's not possible, there should always be an exact link to a reasonable explanation about why you need the process to be so complicated. So far only Georg explained what patches sent to mailing list will not be reviewed, because there is too much volume. But bugtracker is not a patch tracker. It doesn't allow to monitor incoming patches by module, its search is very poor. Of course mailing lists are even worse in this regard, but there is nothing Python community can't deal with. The problem is to keep non-core people outside motivated, and the biggest problem with current documented process is that nobody even thinks about it. -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
2011/2/1 anatoly techtonik techto...@gmail.com: we can definitely find a lot of ways to improve Python development process for general public Definitely. And the future migration to Mercurial will certainly help as well. But this thread started with a patch review, not with a proposal to change the development process! For the moment, we use svn and the issue tracker. If every patch comes with its own workflow, no coordination is possible. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Tue, Feb 1, 2011 at 09:51, anatoly techtonik techto...@gmail.com wrote: On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik techto...@gmail.com wrote: To me polluting tracker with the issues that are neither bugs nor feature requests only makes bug triaging process and search more cumbersome. Anatoly, your constant efforts to try to force python-dev to adapt to *your* way of doing things, instead of being willing to work with the documented processes are *seriously* annoying. Which is a shame, since it obscures the fact that your underlying suggestions are often quite reasonable. I'll abandon my efforts when you prove me that current documented process is a top-notch way for all interested parties to do a quality contributions to make Python better. So that the process is open, straightforward, transparent and doesn't waste people's time more than necessary to communicate a change, make it visible for all interested parties, get feedback, polish and finally integrate. The burden of proof should not be on us to prove to you why we do things the way we do them. I'm not even sure you are familiar with the process that you want to change so badly. You do realize that no one else, from the people in Misc/developers.txt to the one-time patch submitters, has a monthly process gripe, correct? It's certainly working for a few of us. There are many ways for improvement, but if people won't try alternative approaches, they won't see them. This is true of just about anything in the world, but I don't think it's a bad thing. We decided on something, it works, and we use it. I umpire college baseball in my free time and people like to propose tweaks to our on-field mechanics all the time because they think certain alternatives work better. To even get me to think about that stuff is a tall task because not only is my time on the job limited, my actual ability to practice these alternatives is more limited. I'll stick to what's in our book -- it works. I am not sure if I can manage to get to PyCon, so I didn't do any talk preparation, but if by chance I get there and there will be an Open Space, we can definitely find a lot of ways to improve Python development process for general public. I could list a few ways to improve it as well. Do we need any of them to survive? No. The most valuable contributions are coming from professionals, and these people often don't have enough time to follow documented process. Sorry, but sometimes that's the cost of doing business. Just because the court system has a lengthy process for suing people doesn't mean you can skip to the end if you just want to get your money. You have to tell your story first. In the era of information abundance you often have only 140 symbols to communicate the idea, and instead of blaming people of annoying behavior, it might be more useful to make process intuitive and easy to follow. Thankfully Twitter is not our bug tracker. If that's not possible, there should always be an exact link to a reasonable explanation about why you need the process to be so complicated. There's a few things the process is, and complicated it is not. In most cases it is as simple as: report a bug, provide a failing test case, provide a complete patch, review the patch, commit the patch. To an outsider, they don't have to worry about the bug tracker fields, who's doing the commit, what branches it goes into, etc. Just write the code and it'll speak for itself. So far only Georg explained what patches sent to mailing list will not be reviewed, because there is too much volume. But bugtracker is not a patch tracker. Yes it is, or at least that is one of the functions it is currently serving. It doesn't allow to monitor incoming patches by module, its search is very poor. Patches are certainly welcome if you want to make it happen. I think it would be a nice addition. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On 2011-02-01, at 4:51 PM, anatoly techtonik wrote: I'll abandon my efforts when you prove me that current documented process is a top-notch way for all interested parties to do a quality contributions to make Python better. So that the process is open, straightforward, transparent and doesn't waste people's time more than necessary to communicate a change, make it visible for all interested parties, get feedback, polish and finally integrate. There are many ways for improvement, but if people won't try alternative approaches, they won't see them. I am not sure if I can manage to get to PyCon, so I didn't do any talk preparation, but if by chance I get there and there will be an Open Space, we can definitely find a lot of ways to improve Python development process for general public. As well as discuss ways to get around stdlib graveyard and dealing with really complicated problems that won't budge over the years - like out of the box UTC support. The most valuable contributions are coming from professionals, and these people often don't have enough time to follow documented process. In the era of information abundance you often have only 140 symbols to communicate the idea, and instead of blaming people of annoying behavior, it might be more useful to make process intuitive and easy to follow. If that's not possible, there should always be an exact link to a reasonable explanation about why you need the process to be so complicated. So far only Georg explained what patches sent to mailing list will not be reviewed, because there is too much volume. But bugtracker is not a patch tracker. It doesn't allow to monitor incoming patches by module, its search is very poor. Of course mailing lists are even worse in this regard, but there is nothing Python community can't deal with. The problem is to keep non-core people outside motivated, and the biggest problem with current documented process is that nobody even thinks about it. It's nice to see that you want to improve the tracker. I'm happy to point you to the appropriate place for such proposals: http://psf.upfronthosting.co.za/roundup/meta/ The mailing list about the tracker is: http://mail.python.org/mailman/listinfo/tracker-discuss As for the mailing list/patch proposal, I think you should drop it. It's been made abundantly clear, by people much more knowledgable about the dev process of Python than you, why it can't work. Also, not being keen on following the documented process is a good indication, IMHO, of unprofessionalism. -- Virgil Dupras ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
anatoly techtonik writes: I'll abandon my efforts when you prove me that current documented process is a top-notch way for all interested parties to do a quality contributions to make Python better. I think the product of the process speaks very well for the process. The most valuable contributions are coming from professionals, and these people often don't have enough time to follow documented process. I think you have that exactly backward. It is precisely the seasoned professionals who value process most. Professionals are good at managing their own time and can handle process if they can make it routine; but they get annoyed and go away if you break their routine. It's non-professional newcomers who are most attracted by minimal process. the biggest problem with current documented process is that nobody even thinks about it. Look harder. People thinking about the Python process are all over this list, not to mention featured PEP authors. (It's this kind of gratuitous exaggeration that Nick speaks of.) In general, you remind me of the let's import Japanese practices management consultancies of the '80s. They failed dismally, because none of the famous Japanese process innovations are standalone. They depend on each other and on a common culture, both lacking in the U.S. and Europe. That doesn't mean that quality circles, JIT, and the like haven't been successfully applied outside of Japan, but they work differently and organizations had to adapt both the Japanese practices and their existing processes to get any advantage from the innovations. I think the analogy to software process, including in open, open source projects like Python, is quite strong. If you want to change the process, I believe that the most effective way is kaizen, ie, gradually improving by sanding down some rough spots, not by whacking off whole subprocesses that you believe are wasteful. Truly wasteful subprocesses generally don't survive in this environment. You should look harder to figure out what they're good for, and then gradually wean the project from them by providing alternative ways to accomplish those goals that are less wasteful, but compatible with other aspects of the existing process. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On 2011/02/01 07:22:57, techtonik wrote: It removes the dependency from msi.py making it easier to do the rest in subsequent patches. What rest specifically? Why are the msilib changes needed for that? http://codereview.appspot.com/4080047/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
Am 01.02.2011 16:51, schrieb anatoly techtonik: On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik techto...@gmail.com wrote: To me polluting tracker with the issues that are neither bugs nor feature requests only makes bug triaging process and search more cumbersome. Anatoly, your constant efforts to try to force python-dev to adapt to *your* way of doing things, instead of being willing to work with the documented processes are *seriously* annoying. Which is a shame, since it obscures the fact that your underlying suggestions are often quite reasonable. I'll abandon my efforts when you prove me that current documented process is a top-notch way for all interested parties to do a quality contributions to make Python better. And who or what decides what this top-notch way is? So that the process is open, straightforward, transparent Ah. Well, that's definitely very a concise spec. and doesn't waste people's time more than necessary to communicate a change, make it visible for all interested parties, get feedback, polish and finally integrate. [...] The most valuable contributions are coming from professionals, and these people often don't have enough time to follow documented process. In the era of information abundance you often have only 140 symbols to communicate the idea, That's a great idea for a change: report bugs by twitter. We need to set up a twitter search for #PythonBug, and then you simply enter #PythonBug the process is slow and it is converted to an issue on b.p.o. Very open, very transparent, and of course very straightforward. Let's not care about how to reach the submitter when clarification is needed, or what to do about patches. If it doesn't fit into 140 characters, it doesn't exist! and instead of blaming people of annoying behavior, it might be more useful to make process intuitive and easy to follow. If that's not possible, there should always be an exact link to a reasonable explanation about why you need the process to be so complicated. The new devguide (docs.python.org/devguide) should provide exactly that, and in a central location. So far only Georg explained what patches sent to mailing list will not be reviewed, because there is too much volume. But bugtracker is not a patch tracker. As I explained, it is an *issue tracker*. And since in 99% of cases there is an actual issue underlying a patch, it is more than justified to use it to track issues that have patches. It doesn't allow to monitor incoming patches by module, its search is very poor. Of course mailing lists are even worse in this regard, but there is nothing Python community can't deal with. Exactly, so let us continue the ongoing work in improving the tracker. The problem is to keep non-core people outside motivated, and the biggest problem with current documented process is that nobody even thinks about it. I think others already wrote enough about that. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On 02/01/2011 09:51 AM, anatoly techtonik wrote: So far only Georg explained what patches sent to mailing list will not be reviewed, because there is too much volume. But bugtracker is not a patch tracker. It doesn't allow to monitor incoming patches by module, its search is very poor. Of course mailing lists are even worse in this regard, but there is nothing Python community can't deal with. The problem is to keep non-core people outside motivated, and the biggest problem with current documented process is that nobody even thinks about it. I've seen quite a bit of changes over the years. Yes, it's happens over years because the release schedule is fairly long. They try not to interrupt the current schedule too much, so bigger changes to the development process are usually made after a major release is done, rather than during the middle. Lately (the last two years) things have been quite a bit busier with the addition of python3.x. Once we get to where we are (mostly) only concentrating on one major version again, then it will be easer to make process changes. (Less things to mess up if it goes wrong.) I think after this next release is completed you will see more efforts turning to improving the process. Some of the vary things you have been trying to pointed out I think. As far as patches getting attention, it's getting better there too. Every time you make a comment or update an issue with a patch change, it gets reported to the bugs list. Many of the core developers watch that and will add them self to the nosey list on that issue if it has something to do with the parts of python they know. If you have a patch that you feel is complete and is ready to go into the next release or a bug fix for the current one, post a comment on the issue asking for a review. Chances are you will get a reply in a few days. I've found searching for other patches related to my patches helps. I can search the tracker or the bug list for the module or problem I'm working on. It's really not that hard to find related issues. Then I can post a comment on those issues when I can be of help, and also post on that issue a link to the related issue I'm working on. Python is a large project with a *huge* user base. So changes are considered very carefully. Probably the hardest part is making changes in a way that is very unlikely to break someone's program. Mess up someone's pay role process some place (even by the smallest change) and people will get very unhappy really quick. It's also not good to crash space shuttles or google. ;-) Cheers, Ron ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On 2011/02/01 19:50:23, Martin v. Löwis wrote: On 2011/02/01 07:22:57, techtonik wrote: It removes the dependency from msi.py making it easier to do the rest in subsequent patches. What rest specifically? Why are the msilib changes needed for that? The rest is to use ctypes, so that no external packages will be required to build Python installer. http://codereview.appspot.com/4080047/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On 2011/02/02 07:14:17, techtonik wrote: On 2011/02/01 19:50:23, Martin v. Löwis wrote: On 2011/02/01 07:22:57, techtonik wrote: It removes the dependency from msi.py making it easier to do the rest in subsequent patches. What rest specifically? Why are the msilib changes needed for that? The rest is to use ctypes, so that no external packages will be required to build Python installer. Ah. That shouldn't be done. If anything is to be done, the builtin msilib can be considered, instead. Given the choice of using either ctypes or an external package, I prefer the external package. http://codereview.appspot.com/4080047/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On 2011/02/02 07:18:33, Martin v. Löwis wrote: Ah. That shouldn't be done. If anything is to be done, the builtin msilib can be considered, instead. Given the choice of using either ctypes or an external package, I prefer the external package. It is a surprise to find builtin msilib. Why isn't it used? Is an incremental transition to builtin possible? http://codereview.appspot.com/4080047/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On 2011/02/02 07:32:02, techtonik wrote: [...] Can you PLEASE take this off python-dev and move to an issue at bugs.python.org? At least remove python-dev from the CC, or we'll have to temporarily block messages from codereview. http://codereview.appspot.com/4080047/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
Reviewers: , Please review this at http://codereview.appspot.com/4080047/ Affected files: M Tools/msi/msi.py M Tools/msi/msilib.py Index: Tools/msi/msi.py === --- Tools/msi/msi.py(revision 88279) +++ Tools/msi/msi.py(working copy) @@ -4,7 +4,6 @@ import msilib, schema, sequence, os, glob, time, re, shutil, zipfile from msilib import Feature, CAB, Directory, Dialog, Binary, add_data import uisample -from win32com.client import constants from distutils.spawn import find_executable from uuids import product_codes import tempfile @@ -1360,7 +1359,7 @@ # Step 2: Add CAB files i = msilib.MakeInstaller() -db = i.OpenDatabase(msi, constants.msiOpenDatabaseModeTransact) +db = i.OpenDatabase(msi, msilib.msiOpenDatabaseModeTransact) v = db.OpenView(SELECT LastSequence FROM Media) v.Execute(None) Index: Tools/msi/msilib.py === --- Tools/msi/msilib.py (revision 88279) +++ Tools/msi/msilib.py (working copy) @@ -4,7 +4,6 @@ import win32com.client.gencache import win32com.client import pythoncom, pywintypes -from win32com.client import constants import re, string, os, sets, glob, subprocess, sys, _winreg, struct try: @@ -29,6 +28,18 @@ knownbits = datasizemask | type_valid | type_localizable | \ typemask | type_nullable | type_key +# Constants from Windows Installer SDK +msiOpenDatabaseModeReadOnly = 0 +msiOpenDatabaseModeTransact = 1 +msiOpenDatabaseModeDirect = 2 +msiOpenDatabaseModeCreate = 3 +msiColumnInfoNames = 0 +msiColumnInfoTypes = 1 +msiReadStreamInteger = 0 +msiReadStreamBytes = 1 +msiViewModifyInsert = 1 +msidbFileAttributesVital = 512 + # Summary Info Property IDs PID_CODEPAGE=1 PID_TITLE=2 @@ -141,8 +152,7 @@ def gen_schema(destpath, schemapath): d = MakeInstaller() -schema = d.OpenDatabase(schemapath, -win32com.client.constants.msiOpenDatabaseModeReadOnly) +schema = d.OpenDatabase(schemapath, msiOpenDatabaseModeReadOnly) # XXX ORBER BY v=schema.OpenView(SELECT * FROM _Columns) @@ -196,8 +206,7 @@ def gen_sequence(destpath, msipath): dir = os.path.dirname(destpath) d = MakeInstaller() -seqmsi = d.OpenDatabase(msipath, -win32com.client.constants.msiOpenDatabaseModeReadOnly) +seqmsi = d.OpenDatabase(msipath, msiOpenDatabaseModeReadOnly) v = seqmsi.OpenView(SELECT * FROM _Tables); v.Execute(None) @@ -212,7 +221,7 @@ f.write(%s = [\n % table) v1 = seqmsi.OpenView(SELECT * FROM `%s` % table) v1.Execute(None) -info = v1.ColumnInfo(constants.msiColumnInfoTypes) +info = v1.ColumnInfo(msiColumnInfoTypes) while 1: r = v1.Fetch() if not r:break @@ -226,7 +235,7 @@ rec.append(r.StringData(i)) elif info.StringData(i)[0]==v: size = r.DataSize(i) -bytes = r.ReadStream(i, size, constants.msiReadStreamBytes) +bytes = r.ReadStream(i, size, msiReadStreamBytes) bytes = bytes.encode(latin-1) # binary data represented as-is if table == Binary: fname = rec[0]+.bin @@ -275,7 +284,7 @@ r.SetStream(i+1, field.name) else: raise TypeError, Unsupported type %s % field.__class__.__name__ -v.Modify(win32com.client.constants.msiViewModifyInsert, r) +v.Modify(msiViewModifyInsert, r) r.ClearData() v.Close() @@ -298,8 +307,7 @@ ProductCode = ProductCode.upper() d = MakeInstaller() # Create the database -db = d.OpenDatabase(name, - win32com.client.constants.msiOpenDatabaseModeCreate) +db = d.OpenDatabase(name, msiOpenDatabaseModeCreate) # Create the tables for t in schema.tables: t.create(db) @@ -538,7 +546,7 @@ short = self.make_short(file) full = %s|%s % (short, file) filesize = os.stat(absolute).st_size -# constants.msidbFileAttributesVital +# msidbFileAttributesVital # Compressed omitted, since it is the database default # could add r/o, system, hidden attributes = 512 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
Hi, 2011/1/31 techto...@gmail.com: Reviewers: , Please review this at http://codereview.appspot.com/4080047/ [...] It looks good, but did you create an item in the issue tracker? -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
Is there a bugs.python.org issue for this? http://codereview.appspot.com/4080047/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch to clean up the code a bit while I am trying to understand how to add Python to the PATH. I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is more beneficial to development as it doesn't require switching from console to browser for submitting changes. This way tiny changes can be integrated/updated more rapidly. 1. http://mercurial.selenic.com/wiki/ContributingChanges#The_basics:_patches_by_email http://codereview.appspot.com/4080047/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Mon, Jan 31, 2011 at 14:45, techto...@gmail.com wrote: There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch to clean up the code a bit while I am trying to understand how to add Python to the PATH. I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is more beneficial to development as it doesn't require switching from console to browser for submitting changes. This way tiny changes can be integrated/updated more rapidly. 1. http://mercurial.selenic.com/wiki/ContributingChanges#The_basics:_patches_by_email http://codereview.appspot.com/4080047/ Please create an issue. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Mon, 31 Jan 2011 20:45:45 + techto...@gmail.com wrote: I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is more beneficial to development as it doesn't require switching from console to browser for submitting changes. Ok, why don't you contribute to Mercurial instead? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
Am 31.01.2011 21:45, schrieb techto...@gmail.com: There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch to clean up the code a bit while I am trying to understand how to add Python to the PATH. I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is more beneficial to development as it doesn't require switching from console to browser for submitting changes. This way tiny changes can be integrated/updated more rapidly. The tracker is not bureaucracy, it's how our development process works. I know that Mercurial uses a different process, with patches always going to the mailing list and being reviewed there, but that would be way too much volume for python-dev considering our number of patches. BTW, you should be able to send emails to rep...@bugs.python.org in order to create new issues, and attachments will automatically become attached to the bug reports. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
techto...@gmail.com wrote: I see no reason for b.p.o bureaucracy. It provides a place for discussion, and makes it easier to coordinate multiple efforts. ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman et...@stoneleaf.us wrote: techto...@gmail.com wrote: I see no reason for b.p.o bureaucracy. It provides a place for discussion, and makes it easier to coordinate multiple efforts. Code review system provides a better space for discussion if we are speaking about simple code cleanup. To me polluting tracker with the issues that are neither bugs nor feature requests only makes bug triaging process and search more cumbersome. -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Mon, Jan 31, 2011 at 10:58 PM, Georg Brandl g.bra...@gmx.net wrote: Am 31.01.2011 21:45, schrieb techto...@gmail.com: There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch to clean up the code a bit while I am trying to understand how to add Python to the PATH. I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is more beneficial to development as it doesn't require switching from console to browser for submitting changes. This way tiny changes can be integrated/updated more rapidly. The tracker is not bureaucracy, it's how our development process works. Don't you want to improve this process? Code review system is a much better place to review patches than mailing list or bug tracker. Especially patches that are not related to actual bugs. I know that Mercurial uses a different process, with patches always going to the mailing list and being reviewed there, but that would be way too much volume for python-dev considering our number of patches. Seems reasonable. Do you have any stats how many patches are sent weekly and how many of them are actually integrated? BTW, you should be able to send emails to rep...@bugs.python.org in order to create new issues, and attachments will automatically become attached to the bug reports. Thanks. I'll keep this in mind. -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
2011/1/31 anatoly techtonik techto...@gmail.com: On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman et...@stoneleaf.us wrote: techto...@gmail.com wrote: I see no reason for b.p.o bureaucracy. It provides a place for discussion, and makes it easier to coordinate multiple efforts. Code review system provides a better space for discussion if we are speaking about simple code cleanup. To me polluting tracker with the issues that are neither bugs nor feature requests only makes bug triaging process and search more cumbersome. If it's not a bug or a feature request, why does it need to change? -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik techto...@gmail.com wrote: To me polluting tracker with the issues that are neither bugs nor feature requests only makes bug triaging process and search more cumbersome. Anatoly, your constant efforts to try to force python-dev to adapt to *your* way of doing things, instead of being willing to work with the documented processes are *seriously* annoying. Which is a shame, since it obscures the fact that your underlying suggestions are often quite reasonable. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
What's the rationale of this change? It certainly doesn't remove the dependency from win32com.client (i.e. the code continues to depend on win32com). http://codereview.appspot.com/4080047/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
It removes the dependency from msi.py making it easier to do the rest in subsequent patches. http://codereview.appspot.com/4080047/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson benja...@python.org wrote: I see no reason for b.p.o bureaucracy. It provides a place for discussion, and makes it easier to coordinate multiple efforts. Code review system provides a better space for discussion if we are speaking about simple code cleanup. To me polluting tracker with the issues that are neither bugs nor feature requests only makes bug triaging process and search more cumbersome. If it's not a bug or a feature request, why does it need to change? Because code cleanup patches pave road for more complex pieces of work. Clean code makes patches easier to review. It saves developer's time and as a result useful patches are integrated into codebase more quickly. -- anatoly t. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
Am 31.01.2011 22:58, schrieb anatoly techtonik: On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman et...@stoneleaf.us wrote: techto...@gmail.com wrote: I see no reason for b.p.o bureaucracy. It provides a place for discussion, and makes it easier to coordinate multiple efforts. Code review system provides a better space for discussion if we are speaking about simple code cleanup. To me polluting tracker with the issues that are neither bugs nor feature requests only makes bug triaging process and search more cumbersome. Note that while the domain may be bugs.python.org (because that is a traditional name used by many projects), it really is an *issue tracker*, and for us, all patches are issues that should be tracked there. A mailing list works only if you have a small group of core developers who can independently organize the incoming mails using local tools, such as the read/unread marking of the email client. For a larger group this doesn't work (how do you assign a patch to someone using a mailing list?). It sure is more convenient to do patch review, but that's why we are working on Rietveld integration in the tracker. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] MSI: Remove dependency from win32com.client module (issue4080047)
Am 31.01.2011 23:05, schrieb anatoly techtonik: On Mon, Jan 31, 2011 at 10:58 PM, Georg Brandl g.bra...@gmx.net wrote: Am 31.01.2011 21:45, schrieb techto...@gmail.com: There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch to clean up the code a bit while I am trying to understand how to add Python to the PATH. I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is more beneficial to development as it doesn't require switching from console to browser for submitting changes. This way tiny changes can be integrated/updated more rapidly. The tracker is not bureaucracy, it's how our development process works. Don't you want to improve this process? Code review system is a much better place to review patches than mailing list or bug tracker. Especially patches that are not related to actual bugs. If there are patches only on the code review system, others only on the issue tracker, and still others on both, people will get confused quickly. There needs to be a single canonical place to collect issues, and that needs to be the issue tracker (since bug reports cannot go anywhere else). I'm enthusiastic about anything that *improves* this process, but you're proposing to *change* it. I know that Mercurial uses a different process, with patches always going to the mailing list and being reviewed there, but that would be way too much volume for python-dev considering our number of patches. Seems reasonable. Do you have any stats how many patches are sent weekly and how many of them are actually integrated? No, but you can have a look at the weekly Summary of Python tracker issues emails that are sent to this list by a script. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
