Excluding .py files sounds like a terrible idea.
Py files are small. Currently I can go into any addon I want and tweak
it as needed.
This also means that people will need to be able to find the source, and
that will always have to stay up. Otherwise we end up with addons
without source.
Also, how do I check that the .pyc and .pyo files I get match the
source? I trust NVAccess. I don't necesarily trust Random Dev.
On 2/26/2016 11:46 AM, Joseph Lee wrote:
Hi,
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 occur.
* Source code (.py files) will be excluded from the bundle.
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 script.
* The build script and the modified sconstruct go hand in hand.
* 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 (happy with the current approach).
Note that SCons itself (as of 2.4.1) does not support Python 3 (hence 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 projects.
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. Thanks.
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
