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