[nvda-addons] Re: Proposal: excluding .po and .md files when building add-on packages

  • From: "Joseph Lee" <joseph.lee22590@xxxxxxxxx>
  • To: <nvda-addons@xxxxxxxxxxxxx>
  • Date: Fri, 26 Feb 2016 13:17:40 -0800

Hi,
That's a possibility. However, there are disassembly tools out there that'll 
decompile .pyc/.pyo files unless one uses C extensions (.pyd files), and 
because of the license in use, anyone wishing to have their add-ons reviewed 
and included in open-source product must submit source code for initial review 
(if only bytecode were sent, we'll run through disassemblers to make sure the 
bytecode and the source code are happily married; highly unlikely and hope to 
never do that).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx 
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of driemer.riemer@xxxxxxxxx
Sent: Friday, February 26, 2016 1:10 PM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Proposal: excluding .po and .md files when building 
add-on packages

I agree with this and I do not think we should host Adam packages that do not 
have python files because this will encourage other developers to do this in a 
necessarily don't have to put their own source code on their website if they 
don't want to. They could use the template to compile it and never publish the 
source and then we basically made it much easier for them to break the law in 
terms of the copyright of NVDA. I'm not specifically talking about community 
add-ons but third-party add-ons in which the template was used to compile them 
but which the Community rejects for one reason or another.

Sent from my iPhone
Please disregard errors as this is a smaller device.

On Feb 26, 2016, at 13:51, Tyler Spivey <tspivey@xxxxxxxxxx> wrote:

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

----------------------------------------------------------------
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

Other related posts: