I have to say that in add ons a person who is interested in how things are
done can look at the often quite short source and glen some insight into
things. I have on occasion, modified a local copy of an add on, say to
change what was spoken or stop it speaking anything. I am fully aware of
course that when localisation is done, this is not going to work, and most
of the ones i have modified are very simple add ons with no language
settings at all.
I just wonder if all of this really does save significant space or time
though, on modern machines where the memory and disc space is now very
large.
IE is it worth the effort?
Brian
--------------------------------------------------
From: "Noelia" <nrm1977@xxxxxxxxx>
Sent: Saturday, February 27, 2016 5:47 AM
To: <nvda-addons@xxxxxxxxxxxxx>
Subject: [nvda-addons] Re: Proposal: excluding .po and .md files when
building add-on packages
I agree with you.
I wrongly talked about compilation at installation, but I just wanted to
mean letting NVDA to compile the source code.
Thanks for the explanation.
El 27/02/2016 a las 0:49, James Teh escribió:
Compiling the py files at installation is pointless. In that case, you're still bundling the py files anyway, so there's absolutely no advantage at all. IMO, either bundle the py files or just pyc and pyo. Anything in between makes more code with no benefit.
Regarding people not providing source, that can easily be solved by requiring developers to provide a link to version control, a source archive or whatever. Again, that's what happens with other compiled open source packages. If people don't provide this, it's a license violation and the add-on doesn't get accepted.
Finally, all of this only applies to the central add-ons repository. We can't enforce guidelines on anything outside of that and they could already be doing whatever they want anyway.
Still, with all of this backlash, I'd personally suggest just leaving things as they are.
Sent from a mobile device
On 27 Feb 2016, at 8:07 AM, Joseph Lee <joseph.lee22590@xxxxxxxxx> wrote:----------------------------------------------------------------
Hi,
Created the ticket:
https://github.com/nvaccess/nvda/issues/5781
Cheers,
Joseph
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of Noelia
Sent: Friday, February 26, 2016 1:22 PM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Proposal: excluding .po and .md files when
building add-on packages
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ó:included just like it did).
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
As for raising a ticket, I think we should gather comments from otherstable).
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ó:occur.
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
* 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
packages.Advantages of the first method:script.
* 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 (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
savings.projects.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
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
releases.Id 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
Thanks.bugs.
--------------------------------------------------------------------------------------------------------------------------------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
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
