[issue12026] Support more of MSI api

[Irit Katriel]

Irit Katriel  added the comment:

msilib is deprecated as per PEP 594, so there won't be further enhancements to 
it.

--
nosy: +iritkatriel
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12026] Support more of MSI api

[Mark Lawrence]

Changes by Mark Lawrence breamore...@yahoo.co.uk:


--
components: +Windows
nosy: +steve.dower, tim.golden, zach.ware
versions: +Python 3.5 -Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12026
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12026] Support more of MSI api

[Terry J. Reedy]

Terry J. Reedy tjre...@udel.edu added the comment:

Your title mixes a goal -- exposing more of the MSI api -- with a particular 
means -- exposing an object that is only useful with ctypes. So I have taken 
the liberty of removing the implementation limitation. While clever, I do not 
believe that strategy has any precedent in the stdlib. While the stdlib 
includes ctypes, it does not use it to implement functions. While your proposal 
does not directly use ctypes, it does indirectly, by proxy (the user). So I 
think wider discussion, perhaps on pydev or python-idea, to see where the 
proposal falls with respect to current policy, before it could be approved. A 
special feature of msilib is that it is Windows only, where ctypes *should* 
always be available (though even that is not guaranteed if there is no 
maintenance, which there mostly is not at present).

Martin's suggestion is the traditional path. I have 0 knowledge of MSI API. How 
many new functions are we talking about? 10? 100?

--
nosy: +terry.reedy
title: Support more of MSI api by exposing handles - Support more of MSI api

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12026
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12026] Support more of MSI api by exposing handles

[Mark Mc Mahon]

Mark Mc Mahon mtnbikingm...@gmail.com added the comment:

You can pass it to any function in the MSI SDK through ctypes.

e.g. 

def ReadStream(record, field):
buf = (ctypes.c_char * 2048)()
orig_size = ctypes.sizeof(buf)
status = 0
res = []
while status == 0:
size = ctypes.c_long(ctypes.sizeof(buf))
status = msidll.MsiRecordReadStream(
record.hanlde, field, ctypes.byref(buf), ctypes.byref(size))
res.append(buf.raw)
if size.value != orig_size:
break
data = .join(res)
return data


or any of the other functions not currently implemented in _msi.c
Some of the other important ones (to me at least) are:
 - MsiDatabaseGetPrimaryKeys
 - MsiDatabaseExport
 - MsiDatabaseImport

If the whole MSI SDK is wrapped - then exposing the handles would have no use 
:).

The alternative I have so far is to re-write _msi.c using ctypes (already 
done), but I thought it would be better if not all of _msi.c had to be 
re-implemented.

One alternative patch is to include those extra functions in _msi.c (though I 
am not sure I have the C skills to achieve that easily - and it may still miss 
functionality, and it may have even less chance of being accepted)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12026
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12026] Support more of MSI api by exposing handles

[Martin v . Löwis]

Martin v. Löwis mar...@v.loewis.de added the comment:

I'd rather expose the missing functions, than supporting a mix of this module 
with a ctypes one; this patch sounds hackish.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12026
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12026] Support more of MSI api by exposing handles

[Martin v . Löwis]

Martin v. Löwis mar...@v.loewis.de added the comment:

What's the purpose of the patch? I.e. what can you do when you have the handle 
exposed?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12026
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12026] Support more of MSI api by exposing handles

[Mark Mc Mahon]

New submission from Mark Mc Mahon mtnbikingm...@gmail.com:

Background:
My main use case for msilib is for working with/editing existing MSI files and 
not creating MSI files.

As such I find much of the MSI API that I need missing.

While not difficult to re-create _msi.c with ctypes, I thought it might be good 
to use as much of _msi.c as implemented (faster :) )

Patch:
The patch exposes the 'h' member of msiobj as 'handle', and updates the doc to 
refer to them.

There are no tests in the patch yet. Any recommendation on tests? (just check 
that the member exists and has an 'int' value?

--
components: Library (Lib)
files: expose_msi.c_handles.diff
keywords: patch
messages: 135401
nosy: loewis, markm
priority: normal
severity: normal
status: open
title: Support more of MSI api by exposing handles
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file21914/expose_msi.c_handles.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12026
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com