Doubt about developing plugins for python applications
Dear Gurus, I have a question about plugins structure, and I would like to get some advise from you. It is basically related to how I can reach a private module (for python applications) while compiling a plugin that uses that module. I have an application to which I would like to add some external plugins, that will be essentially part of the application, thus using its existing modules, but adding functionality to the main application. For that, I designed the following structure: program/ | | program.py | | programlib/ | | setup.py | | plugins/ | | where program.py is the application entry point, which uses the programlib package, and so the plugins. The plugins have access to all packages/modules within programlib and to their own directory tree. In this sense, the programlib is shared by the main program and its plugins, but it is still private to the rest of python. When compiling/building the source with setup.py, I encountered the problem that separating the plugin as an independent solution: program/ | | setup.py | | plugins/ | | | |--pluginA/ | | the setup.py fails (obviously) because it does not find the packages/modules from programlib, which are only available to the main application source. Installing program from source, the setup.py places the files under dist-packages, making programlib accessible to the program-pluginA setup.py. But as being an application, the debian packaging will install it into /usr/share/program, so the compilation of the plugin will fail. Long story short, I guess my question is: what would be the best way to overcome this problem? I can see a couple of workarounds, but I do not know the best approach, or if there are alternatives to what I have in mind. I could think of: a) make the package programlib public (meaning storing the files in pymodules/dist-packages) - but this does not seem good solution, because it does not have any need for programlib to be accessible by all python code or b) add current installation to python path (eg. /usr/share/program) so the plugin can import the programlib packages/modules. What would you suggest me to do? Thank you for your help. -- *Braga, Bruno* www.brunobraga.net bruno.br...@gmail.com
public python package that maybe should be privite.
Newbe type question. My upstream python program also has a python package that it uses. It is now setup to be a public package. But maybe it should be made private. It could, in theory, be used by another program but; It has almost no documentation or comments including the special python comments that turn into documentation. Anyone wishing to use this package would have to study the source code. Should I drop a bug on the upstream and turn this into an undocumented public debian package? If so, is there any special trick to separate the files that go with the new package? Or should I drop a bug on the upstream and turn it into a private python package, installed in a non public place? If I should do this, what is the standard, established, way of altering the various python path type variables so that import still finds this moved package? -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: shebang lines for Python scripts
Apologies for reviving this thread. It's recently come up in relation to
other discussions I've had and I did a grep over s/usr/bin to find instances
where "/usr/bin/env python" was being used. Stefano reminded me of this
thread, and when I went back and re-read it, I noticed there wasn't resolution
on all the issues.
On Mar 04, 2011, at 11:23 PM, Piotr Ożarowski wrote:
>any objections to change all shebangs (that do not match
>/usr/bin/python\d(\.\d+) but do math .+python.* regexp) to
>/usr/bin/python¹ in dh_python2 and to /usr/bin/python3 in
>dh_python3?
>
>(+ an option to disable this behaviour in both helpers)
>
>if yes, should options (-OO, etc.) be removed as well?
>
>[¹] or /usr/bin/python2, depends on PEP 394 status
As a reminder, the issue is that, in development (i.e. upstream) packages,
it's perfectly fine to use "/usr/bin/env python" on the shebang line.
However, I feel strongly that *installed* Python scripts, should never use
this, and instead should use "/usr/bin/python" or possibly
"/usr/bin/pythonX.Y".
(Stefano brought up a legitimate case where this could prove inconvenient, but
I think it's more important to have a functioning system :).
There were two good proposals in the thread:
- Debian Python policy should be stronger in its recommendation to use
/usr/bin/python or /usr/bin/pythonX.Y in the shebang line instead of
/usr/bin/env python.
- dh_python{2,3} should rewrite the shebang lines by default, with an option
to disable that.
I just had a look at D-P policy $1.4.2 and it is stronger now than what Scott
quoted back in March 2011. Here's what it says now:
1.4.2. Interpreter Location
---
The preferred specification for the Python interpreter is
`/usr/bin/python' or `/usr/bin/python.'. This ensures that a
Debian installation of python is used and all dependencies on
additional python modules are met.
Maintainers should not override the Debian Python interpreter using
`/usr/bin/env python' or `/usr/bin/env python.'. This is not
advisable as it bypasses Debian's dependency checking and makes the
package vulnerable to incomplete local installations of python.
I like this. It strikes the right balance, and strongly discourages using
/usr/bin/env.
On the second point, I don't think Piotr ever implemented shebang line
rewriting. I think it would be a good idea to have the helpers help you
conform to D-P policy, so I support adding a feature to dh_python{2,3} to do
this, with an option to disable it.
Of course, this won't help packages that don't use the helpers. They'll still
do the wrong thing unless the packager takes action. But at least we can
point to the rationale in D-P policy, and this thread to explain why
/usr/bin/env is usually a bad idea.
Cheers,
-Barry
signature.asc
Description: PGP signature
Re: RFS: python-unicodecsv (Closes: #669678)
i fixed all the stuff (see comments below) and uploaded a new package to mentors.debian.net . if there are no other issues, i'll add the debian-dir to the python-modules svn (i'm a team member since some days, my name is toabctl-guest) and search for a sponsor. Many thanks for the help, Jakub! On Mon, 2012-04-23 at 20:03 +0200, Jakub Wilk wrote: > Lintian now emits: > W: python-unicodecsv source: debhelper-overrides-need-versioned-build-depends > (>= 7.0.50~) > I: python-unicodecsv source: quilt-patch-missing-description > 01disable_float_double_tests.diff fixed on mentors.debian.net > * Thomas Bechtold , 2012-04-23, 18:32: > Please run tests at build time. > >>>fixed in debian/rules > >>It should be override_dh_auto_test, not overwrite_dh_auto_test. Please > >>honour DEB_BUILD_OPTIONS=nocheck. > > > >fixed both on mentors.debian.net . > >seems that the tests never run. fixed this as well and disabled 2 tests > >(see debian/patches) because the tests failed. > > How about fixing the tests rather than disabling them? :) See the > attached patch. thanks. i forwarded the patch upstream and included the patch in debian/patches > >>Please test against all supported Python versions, not only the > >>default one. > > > >at build time? how to do this? what are the build dependencies in > >debian/control > > python-all done. > > >and what should i do in debian/rules ? do you have an example package maybe? > > Use "pyversions -r" to get list of supported Python versions, then > iterate over them. TIMTOWTDI: > 1) abuse %-rules, see e.g. flufl.enum; > 2) use a for loop, see e.g. sphinxcontrib-speeling; > 3) (my favourite:) use xargs, see e.g. python-byteplay. done with your favourite. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1335415687.2744.5.ca...@salbei.fritz.box
