OK, some people is reporting feed-back on this too.
But for now I think it's better to include source files, so that NVDA
can generate pyw or pyc.
Really I'm used to look add-ons not included in our website before
installing them. I prefer to get a look on the source code since it's
possible that something wrong or harmful is coming in add-ons.
At least we see a big advantage excluding source, I'd like not to do it.
Thanks.
El 26/02/2016 a las 22:11, Joseph Lee escribió:
Hi,
Compiling during installation means either we use compileall or know what to
pass in to py_compile (unlike compileall, py_compile does come with NVDA),
so it may not work out as intended.
As for removing source files: Jamie said one should remove .py files if one
removes .po and .md files for consistency (after all, an end user using
binary builds don't see the source code unless one is really curious about
how it works or need to look at it, for which fetching from repos or
downloading the source as a zip file is the best solution). When I wrote the
proposal and possible solutions, I put source code removal as an optional
switch (by default, it'll be included just like it did).
As for raising a ticket, I think we should gather comments from other add-on
writers before we create one so we can receive some input from the add-ons
community.
Cheers,
Joseph
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of Noelia
Sent: Friday, February 26, 2016 12:53 PM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Proposal: excluding .po and .md files when
building add-on packages
Hi. In case that binaries require (for now) pyc and pyw files if source
isn't included, I think it's easier just to include source and let NVDA to
compile add-ons in installation.
Perhaps it would be better to take care about things as an open ticket time
ago, about deactivating individual add-ons and work on this, for instance,
or on layered commands, saying things using in add-ons..
Thanks.
El 26/02/2016 a las 20:46, Joseph Lee escribió:
Hi,occur.
Found a possible way, although this will require additional work that
might hopefully be automated later:
1. Before running "scons', you must perform the following:
python -m compileall -d None addon/
python -O -m compileall -d None addon/ You must specify "None" for
destination folder, otherwise addonHandler complaints the resulting
bytecode is not a proper add-on code.
2. Run scons as usual with the modifications specified below.
The proposed modifications to addonTemplate/sconstruct are:
1. Two new command-line switches will be introduced to control
bytecode generation and control output verbosity (possibly named
"package" (defaults to False) and "verbose" (defaults to True)).
2. If "package" is true:
* Bytecode compilation will be the very first item performed, and the
paths to bytecode cache will be recorded. If "verbose" is true, names
of .py files will be shown. This is the earliest phase where errors may
* Source code (.py files) will be excluded from the bundle.script.
2. Proceed as before.
Another idea is to create a "build" script that calls SCons with or
without going through bytecode generation first. This build script
will take in two optional switches:
* py3 (defaults to False): Creates a Python 3.x compatible bytecode
(2.7 if false).
* source (defaults to True): Let's SCons include source code files
(mostly useful on debug builds generated from branches other than stable).
Advantages of the first method:
* If people have necessary build environments, they can use SCons like
what they've been doing.
* The additional switches will be used by release managers and others
who needs to distribute add-ons.
Disadvantages of the first method:
* Needs a lot of testing after modifying addonTemplate/sconstruct.
* It isn't advisable to use os.system or its friends to execute
scripts (could be a security risk) unless if it is truly needed.
Advantages of the second method;
* Only those who'd like finer control over add-on compilation would
grab this additional file (and the modified sconstruct).
* The build script can be tuned to target different Python releases
before calling SCons.
Disadvantages of the second method:
* Burden of maintaining two files: modified sconstruct and the build
* The build script and the modified sconstruct go hand in hand.(happy with the current approach).
* Build script may open security holes (this is caling Python scripts).
Ideally, the second method is much preferable (hopefully it could
support bytecode generation under Python 2.7, 3.2, 3.5 and beyond),
but I understand that the first method is useful in certain
situations, namely if you don't need finer control over add-on generation
Note that SCons itself (as of 2.4.1) does not support Python 3 (henceprojects.
you cannot build NVDA under Python 3). Although both methods may mean
slightly slower (but unnoticeable) compilation speed, it guarantees
that the bytecode is ready for use out of the box (at load time). Of
course, it'd be a different story if (only) source code was included.
Comments are appreciated.
Cheers,
Joseph
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of James Teh
Sent: Friday, February 26, 2016 4:18 AM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Proposal: excluding .po and .md files when
building add-on packages
Oh. I just realised that if you exclude .py, you'll need to include
both .pyc and .pyo, which is actually quite tricky to manage. So
perhaps not a good idea.
Jamie
On 26/02/2016 10:10 PM, Noelia wrote:
Just a question. I vote for consistancy, wether or not Py files are
included.
But, if they are excluded, should be included pyc and pyw files?
Thanks.
El 26/02/2016 a las 13:01, James Teh escribió:
Personally, I'd drop the source (including .py files) from the packages.
If these were compiled binaries, we wouldn't be bundling the source
with the binaries. Also, if people want to learn about development
by example, it's not unreasonable to expect them to learn about
fetching the source. That's what they'd have to do in fully compiled
Thanks.That said, I realise this viewpoint is probably going to be
unpopular, and for add-ons, I don't care strongly enough to push it.
For consistency, if you're going to include .py files, you may as
well include .po and .md as well.
Jamie
On 26/02/2016 9:45 PM, Joseph Lee wrote:
Hi,
Hmmm, perhaps an optional command-line switch (invoked by release
managers)
might be useful for cases where excluding .po and .md files would
be useful (for example, if the space is tight). Without this
command-line switch specified, add-on bundles would include
everything like what we have now.
Mick or Jamie (and others), any thoughts on this?
Cheers,
Joseph
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of Noelia
Sent: Friday, February 26, 2016 3:35 AM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Proposal: excluding .po and .md files
when building add-on packages
I disagree.
If Python files are not excluded, I think that po and md files
shouldn't be excluded for consistancy.
NVDA excludes the source code in binaries, but add-ons are smaller
and the source code allows modifications and learning about
development.
Furthermore, if some files are excluded, perhaps detailed
documentation about building add-ons from source is required, and
perhaps the readme of add-on template is not enough.
I remember a similar discussion time ago.
Thanks.
El 26/02/2016 a las 12:16, Joseph Lee escribió:
Hi all,
When NVDA is compiled, various nvda.po files are excluded, leaving
only .mo files. Same applies to readme - .t2t files are excluded,
leaving .html files. This results in significant disk space savings.
I’d like to propose that a modification to
addonTemplate/sconstruct be made to exclude .po and .md files
starting with our upcoming spring/fall quarterly maintenance releases.
--------------------------------------------------------------------------------------------------------------------------------Cheers,----------------------------------------------------------------
Joseph
NVDA add-ons: A list to discuss add-on code enhancements and for
reporting bugs.
Community addons are available from: http://addons.nvda-project.org ;
To send a message to the list: nvda-addons@xxxxxxxxxxxxx To change
your list
settings/unsubscribe: //www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx
----------------------------------------------------------------
NVDA add-ons: A list to discuss add-on code enhancements and for
reporting bugs.
Community addons are available from: http://addons.nvda-project.org ;
To send a message to the list: nvda-addons@xxxxxxxxxxxxx To change
your list settings/unsubscribe:
//www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx
NVDA add-ons: A list to discuss add-on code enhancements and for
reporting bugs.
Community addons are available from: http://addons.nvda-project.org ;
To send a message to the list: nvda-addons@xxxxxxxxxxxxx To change
your list settings/unsubscribe:
//www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx
NVDA add-ons: A list to discuss add-on code enhancements and for reporting
bugs.
Community addons are available from: http://addons.nvda-project.org To send
a message to the list: nvda-addons@xxxxxxxxxxxxx To change your list
settings/unsubscribe: //www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx
----------------------------------------------------------------
NVDA add-ons: A list to discuss add-on code enhancements and for reporting
bugs.
Community addons are available from: http://addons.nvda-project.org
To send a message to the list: nvda-addons@xxxxxxxxxxxxx
To change your list settings/unsubscribe:
//www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx
