yashsingh1/xdaforums huggingface dataset:
[Android Software Development] strvmarv:
Awesome, will take a look tonight. It's very likely I'm just not setting the options in the setup.py correctly.

You're running snow leopard, correct? You could grab a copy of the Windows 8.1 Preview (free until Jan something I believe - http://preview.windows.com) and dual-boot, or even just run a VM...if you wanted. I had to install Python 2.7 x86, wxPython x86, python2exe x86, and then run derp.py from source directly (powershell or cmd) to get where I'm at now.
[Android Software Development] fattire:
Ideally I'd like to test it on a win32 system because that's the one that py2exe will make a .exe for. But that said, hashcode has it running and adb installs and works and such. It's now a matter of getting it packaged up properly I think. If you can double-check that it works for you, that would be a good start. Then hopefully the .exe can be made. It should also check to make sure java is installed (which is needed by the Google updater) and if not, maybe help the user do it (or even do it for them)...

Also, his version of windows already had drivers on them, so we're not sure whether derp (well, the android tools installer from Google) will take care of that or not.

One last note-- you may have had problems with the looping downloads because the sha512sum seemed to have been off. I did my own sha and it was different.. The new one worked for hashcode.. it's in his commit linked above..

Thanks!
[Android Software Development] strvmarv:
* on win32 does it build into an .exe?

- I'm not win32, I'm running 8.1 x64, but it builds/executes just fine if you're using the 32 bit versions of Python, wxPython, and py2exe due to WOW64, long story

- It does build into an exe, see screen

Output

View attachment 2167579

Screen of dist folder

View attachment 2167586

* If so, does the .exe run properly as the administrator-- right-click and select "Run as Administrator" I am told

- I'm running it with Run as Administrator, no, it still seems to blow up and stop running when it get's to __init__, it appears it can't find it for some reason when built with py2exe, likely the need for inclusion, not exactly sure yet...hard to capture error since it flashes by very quickly and then the console closes

* if so, does it install the android tools and ask you to agree to the License?

- If I run derp.py directly in Python it works just fine, android tools, etc...I haven't tried a script yet

* if so, does it download/detect your devices?

- I haven't tried a script yet

* if so, can you run scripts (does it work?)

- Ditto

Note: You may also need to manually install Java, since the android sdk updater uses java.

- Java SDK already installed, I dabble in Android

These missing modules indicated in build output worry me, not certain how to install them...

The following modules appear to be missing

['Carbon', 'Carbon.Files', 'ElementC14N', '_scproxy', '_sysconfigdata', 'win32api', 'win32con', 'win32pipe']

I've pulled a fresh copy of your repo, added Hashcodes changes, and tweaked the setup.py according to what I've found so far. Still blowing up as indicated above, but still moving in the right direction. If you want to go ahead and merge Hashcode's pull and ignore mine I'll reapply my changes so things don't get weird.

Pull request 2: https://github.com/fat-tire/derp/pull/2

I'll look over py2exe documentation and see if I can figure out what we need to change.
[Android Software Development] strvmarv:
Ah, now we're getting somewhere, I changed console=["src/derp.py"] to windows=["src/derp.py"] as indicated here http://www.py2exe.org/index.cgi/ListOfOptions , get an error on execute, which is dumped into a text file, and looks like this...

Traceback (most recent call last):

File "derp.py", line 48, in <module>

NameError: name '__file__' is not defined

Any ideas?

scriptFolder = os.path.join(os.path.dirname(os.path.realpath(__file__)), "..", "scripts/")

View attachment 2167624

UPDATE:

This may help...

http://stackoverflow.com/questions/...e-path-of-the-current-executed-file-in-python
[Android Software Development] fattire:
Nice.. thanks!

Ah, cool.

The file size looks tiny... it looks like it doesn't build into it all the stuff it needs...

^ This is awesome and a good sign for this working once we get the build finished.

Now that I think about it-- the "welcome" stuff and auto-download of the tools are all a running .derp script (welcome.derp) so yes, you are running them :)

Hmm.. Did you try adding them explicitly in the optionList as I suggested above?

And another way to do it is to use the -p and -i paremeters when you do python setup.py py2exe

Also maybe try adding:

import win32com

after "import py2exe" in setup.py I saw some reference to that somewhere...

What else...

looks like elementc14n is something related to the elementree module of python... win32api is here I think... but I think it would be installed when you installed python to begin with.

I'm looking too... See this?

For py2exe to work with packages loaded during runtime, the main thing seems to be that u explicitly import the modules needed by your app somewhere in your app. And then give py2exe in setup.py with moudlefinder.AddPackagePath( , ) the hint, where to search for modules it couldn't find by std. introspection. in the app

I won't do a full-on pull to the repo until everything is working and tested against linux/mac just to make sure we're only fixing stuff and not breaking the other platforms in the process ;)
[Android Software Development] fattire:
Ah yes-- does this help as recommended in the link above..?

http://www.py2exe.org/index.cgi/WhereAmI
[Android Software Development] strvmarv:
jpath wouldn't pull in for some reason, despite installing via pip and having an import, so I resorted to logic to assign "." as the path (very hacky)...

So, here it is...running from derp.exe compiled with py2exe...when I get a moment I'll put together a quick summary of how to get a local win environment going..

View attachment 2167773

Here's another pull:

https://github.com/fat-tire/derp/pull/3

UPDATE:

Ack, storing sdk tools in Program Files\Common Files is great and everything, but it needs to be store in Program Files (x86)\Common Files since it's x86 compiled. Pretty sure things may go wrong at some point as it is...
[Android Software Development] fattire:
I'm on my phone now so I'll look in detail ina few hours but this looks awesome. Fell free to change the DL directory to wherever is appropriate... I don't know windows. Do notice that android.bat and the tools are run as admin so you don't want to put it somewhere a non anon can change or replace them. In Linux it sets the permissions to root only. Does it work for windows too?

If you update the pull req., can you add the makefile changes too? And also if you run as non admin maybe it should pop-up and tell you to right click and run as admin?

Oh and last thing it would need I think is to verify java is installed and maybe install if it isn't.. Am I forgetting anything?
[Android Software Development] strvmarv:
Windows can certainly restrict a directories permissions to admin only, but I'm not quite certain how to do it via Python.

I'll take a look at the makefile. I'd typically write a little script that "attempts" to write to an existing system directory and if it fails throw a message that the user isn't running as admin.

Detecting Java could be interesting...

IMHO, such a download should be isolated to the app's working directory, especially if the app is portable and doesn't require any sort of installation. Right now I'm just using ".", but unfortunately it's having issues firing android.bat after extraction...looking at that now...

PS C:\users\paul\dev\derp\dist> python ../src/derp.py

DERP: -----Welcome to The DERP Installer!-----

DERP: -----Starting New Script: ..\scripts/derp\welcome\welcome.derp-----

DERP: Debug Mode set to: False

DERP: ACTION : Updating SDK Tools...

DERP: Checking for SDK...

DERP: SDK found. No need to get it again!

DERP: ACTION : [.\tools\android-sdk-windows\tools\android.bat update sdk --no-ui --filter platform-tool, tool]

DERP: ^^ OUTPUT : The system cannot find the path specified.

DERP: ^^ OUTPUT :

DERP: ACTION : [.\tools\android-sdk-windows\tools\android.bat update adb]

DERP: ^^ OUTPUT : The system cannot find the path specified.

DERP: ^^ OUTPUT :

DERP: ACTION : [.\tools\android-sdk-windows\platform-tools\adb kill-server]

Exception in thread Thread-3:

Traceback (most recent call last):

File "C:\Python27\lib\threading.py", line 808, in __bootstrap_inner

self.run()

File "../src/derp.py", line 132, in run

stdout=subprocess.PIPE, stdin=subprocess.PIPE, cwd=self.cwd)

File "C:\Python27\lib\subprocess.py", line 711, in __init__

errread, errwrite)

File "C:\Python27\lib\subprocess.py", line 948, in _execute_child

startupinfo)

WindowsError: [Error 2] The system cannot find the file specified
[Android Software Development] fattire:
It should already be doing it... can you run anything as a regular user that's in the sdk now?

All you have to do is add an entry just like the mac one that runs the python setup.py py2exe line. then add "win" to the PHONY list... this is assuming that you can use "make" in Windows... which I guess is an assumption that may not be correct.

Apprently it's not that hard according to this.

For an installation of a 3rd party thing, such as the Android Tools, it probably shouldn't be linked to the app's directory. If it's anything like Linux/Mac, it should be in a 'known' place appropriate for application support... Especially since the .exe can be run from anywhere I would think. It would be ideal to have a known place.. Doesn't windows have some kind of support directory where applications put libraries or something? Although this isn't a library-- it is a support type of thing.. OS X has "/Library/Application Support" for example...

FWIW, hashcode and I got the download and install working using the Common FIles/ directory. It installed tools to the c:/Program Files/Common Files/Derp/tools and downloaded files to the c:/Program Files/Common Files/Derp/downloads without a problem... (I'm not sure those were the exact paths, but y'know, close...)

I would avoid using any kind of "./" at all costs. Use an absolute path to the tools and download. Aside from the security issues it may raise, as the Derp.exe file may be run from different places at different times, you dont' want the sdk to be re-downloaded and re-installed over and over every time.. and who knows where those directories may be... and remember, they're installed and run as root... cleaning up that stuff may be an issue too. Best to find the best place for Windows for those things I think...
[Android Software Development] strvmarv:
Ok, if I revert to hard-coded fully qualified paths I get farther...now the progress bar just goes nuts and seems to run indefinitely...I can't attribute the behavior to not working though so I'll just let it run and see what happens from here...

If I run it as a python script it locks up when trying to shutdown ADB, which if I kill ADB manually it continues on just fine.
[Android Software Development] fattire:
When it goes nuts... look at the console and see what it's doing (view->console I think)

Also-- in teh console you can see what it's trying to do-- and you can try replicating it from teh command line to see if it's adb screwing up, or python.... not sure why it worked so well for hashcode... though he was running straight from python, not the exe..

(we're getting close though I think)...
[Android Software Development] strvmarv:
Good info, was having to run it directly in python to see that...here's what it's doing, which shouldn't be taking this long...much shorter when I run it manually...will wait it out and see...

ACTION : [C:\Program Files\Common Files\derp\tools\android-sdk-windows\tools\android.bat update sdk --no-ui --filter platform-tool, tool]

Runs much more smoothly directly in python until I get to ADB.

---------- Post added at 10:06 PM ---------- Previous post was at 09:59 PM ----------

I couldn't avoid "." when __file__ was called, you're welcome to swap it out. I branched the logic to only use "." with Windows.

In the Windows world this isn't really an installation, more just supporting framework. Residing in Program Files does allow it to utilize the existing admin permissions requirements, but for all intensive purposes, being a 32bit app, it should reside in Program Files (x86) on a 64bit machine but Program Files on a 32 bit machine (sigh). Doesn't concern me at this point, especially since these are typically just registry and OS level semantics that haven't really come into play.
[Android Software Development] fattire:
Okay... the updater usually just checks to see if there's a new version. If there is it downloads and installs it. (first time it downloads it all because there's nothing to update) but you should see progress in the console as it downloads and updates stuff...

Is there some kind of windows installer that will put it in the right place, or would a folder, zipped, with the .exe and maybe a LICENSE and README be the right way to do it? Also, let's say someone puts the .exe on the desktop and runs it-- won't it create the tools folder and stuff on the Desktop too, since that's where the .exe is? And what if they then say "oh, I don't want all this stuff here with the admin settings" and then move the .exe to a subfolder, wouldn't it have to re-download everything? (or same thing if they move the tools folders themselves instead...? Now there's one copy in the trash, and if they re-run derp it will recreate it again, etc...?)

Again, you're the expert on how Windows "supporting framework" works--- maybe Program Files (x86) is right if we're gonna use an absolute path for the tools? I mean I guess since they may move the .exe around, setting an absolute path for the tools/downloads is the right way? I'm so out of my element with this, clearly. I haven't used Windows since Windows 95.

Update: BTW, I think the reason I needed the location that the script is running is so that when you choose File->Open Script, it'll default to the /scripts/ directory, making it easier to choose the built-in scripts (to install to Nexus 7, HTC One, etc...) If there's a more windowsy way to do this, by all means do it :)
[Android Software Development] strvmarv:
Yes, there's plenty of windows installer options, but I highly recommend skipping the installer and sticking with portability. A self-contained, self-updating, isolated app is the way to go in my opinion, especially when you consider your potential audience. Most of those users will never even use the SDK beyond derp. Downloading 249mb of supporting files into a completely separate directory and not cleaning up these files in case of app removal is not necessarily a good idea. If you're not using an installer that means it must be contained in the app's directory so the files are automatically deleted along with the app. Besides, is the download really all that painful these days? If so, maybe bundling a copy of the sdk (if the license allows it) would be a better idea. Also, it's very likely that the sdk has built-in behavior for handling elevation of the user to admin while executing (haven't tried it, but would be mildly shocked if there wasn't at least an error message displayed).

Good god, windows 95 was a huge pile of pooh piled on top of ms-dos, which made me miss ms-dos. Using absolute paths in Windows will get you in to trouble (unless you're speaking UNC, which is a completely different ideal). In your world "/" means system drive, correct? Not so in Windows. C: is typically the system drive, but there is absolutely no guarantee as such, it could just as easily be D:, believe me, been there when the client said "why doesn't your installer support D: as the system drive" (facepalm). There are system environment variables dedicated to holding the dynamic values of these locations, including the program files folder (http://technet.microsoft.com/en-us/library/hh825266.aspx). There's likely a way to retrieve these variables through python, just haven't researched it.

In the Windows world (related to WOW64 if you want a TLDR on wikipedia):

On an x64 machine

Program Files is for x64 apps, Program Files (x86) is for x86 apps

On an x86 machine

Program Files is for all apps, because all they can run is x86

Doesn't "./scripts/" accomplish the same thing? This directory will always be under the executing binaries directory, correct?

I would highly recommend making an effort to setup a local windows vm and become mildly familiar with the platform if you plan on full-fledged windows support. At the very least it gives you context when requests or issues are inbound. Anyways, this is just one windows developer's perspective and by no means the only perspective, nor the correct perspective. This is your baby. Believe me, I butt heads with the old-timers at work all the time.
[Android Software Development] fattire:
I totally agree. an .exe is preferable to some installer...

FWIW-- The sdk that's d/l'd from google isn't the full sdk-- it's just the android tools part.. it filters out the development stuff to just the essentials..

I guess that's fine.. it breaks with linux/mac where the SDK is not uninstalled-- there was a lot of internal discussion about whether deleting derp should delete the sdk as well (only linux has an uninstaller.. for mac the general practice w/o an installer is to leave the support libraries there) and people seemed to think that the sdk was its own product-- people may use derp simply as a front end for downloading/installing the SDK tools... because the android tools may be of value w/o derp.

Well this is possible I suppose, but (1) it makes derp bigger, as you say, (2) the infrastructure for downloading and updating and agreeing to the license (which would be necessary) is already built into derp, and required for the other platforms, (3) the method for #2 is already built into derp's installer functionality anyway, (3) we're always sure from v0.001 that adb and fastboot will be up to date, even if derp is run 5 years from now. This is important, because adb is always gaining functionality, such as the device SSL stuff that showed up in 4.2... that would cause huge issues if it had happened to a user who installed derp if it existed in early 2012. the android tools updater updates itself too, so it's kinda like "leave the installing to the installer" thing...

I can only speak for linux/osx... if they're not run as root, you run into driver, udev, and "device not found" errors without explanation.

Yes, I think this is the way to go, at least for parity with the other platforms-- if there is a way to ascertain where teh program files is (or the common files or whatever the right place is), then let's have it auto-detect and use that...

BTW, I'm thinking version 0.002 can have a "Uninstall Android tools" option that just wipes out the directory. In fact, I should make an Issues list with desired features like that. I also before I forget should add a preference to download the tools from Debian's repository on ARM systems. Because derp DOES work on arm systems, although using an arm-compiled version will have potential "not using the latest version" issues as described above...

Yes-- ./scripts would work, if . is the currently running directory where src/derp.py can be found... I think. Again, I assume that it's the same in Windows as other platforms... but that's an uniformed assumption..

I'll be lost, but I can try :) IT's good to get the perspective of at least one Windows person... I only know linux and os x folks for the most part.. I do think though, from what it sounds like, that it does run... just need to get these little things set..
[Android Software Development] fattire:
Some new insights...

For lines 50 and 94 in your version...

os.path.dirname(".") to os.path.abspath("")

Also, to get the Android USB driver added automatically, line 977 needs to have this added to add the Google USB drivers.

"platform-tool, tool, extra-google-usb_driver" <-- this last bit here. It can be added to all platforms and will be ignored on non Windows machines.

Now those latest drivers are put in place in the sdk location, but are not automatically installed. Is there a way to automatically find and install them once the sdk updater installs them? Like a scripted method to run the Device Manager thing (via command line?) and get them to install?

After installing that and Java, I think it's pretty close to working...
[Android Software Development] mateorod:
I have been maintaining a program that supports Linux/OSX/Windows for a couple years(ahh...more like a year and a half) now...it can be done! I will say though, that the time has periodically come when I simply had to go find a Windows box and really test myself. For the first year, I had a very willing and able Windows maintainer..but this is the internet and collaborators move on. Good luck, I am following along.

We leverage github to auto-update, speaking of that feature.
[Android Software Development] fattire:
So yeah it looks like the actual Windows port is done, really, in the sense that it runs 100% as far as I can tell one the drivers are in and everything. It's just a matter of deciding the best way to package it so that the Android tools go in the right place (and decide where that should be), as well as make sure Java and the google usb drivers gets installed as well... I really need to understand how windows stuff is normally packaged.
[Android Software Development] fattire:
Dunno if this will work, but...

So here's a diff (raw) against my current github version which has some windows things.

Use

python setup.py py2exe

and then run what's in /dist (which I think should be movable).

In addition to what's been done so far...

Keeps /tools and /downloads (the android tools + downloads) in the install (/dist) directory) as recommended by strvmarv

fixes sha/md5 checksum bug

automatically updates google-provided usb drivers and installs them (>vista required)

checks to see if it's running as windows admin and advises how to do it.

checks to make sure java is installed (required by the Android tools updater)

doesn't pop up command-line window every time a subprocess runs

copies sample derp scripts & tutorial and welcome and such to the install (/dist) directory properly.

miscellaneous stuff to platform dependent stuff

changes app icon to derp.ico (has to be put in /res/drawables/derp.ico ) <-- this is needed. Put anythign here until I make one.

probably more.

The tutorial now doesn't exclude windows.

NOTE-- this breaks unix/osx builds right now (because of the addition of creationflags=0x08000000 to the subprocess command), but that can be reconciled. If anyone wants to try it though on Windows, that would be cool. I think anything post-Vista would be good to try it on.

Also, if you want to try it with an existing install script for one of the devices, you need to take out the os="Linux Darwin" on line #1 of the derp script.

thanks!
[AT&T Samsung Galaxy Note I717] JEZZEJAMEZ:
So now they been out a whole min. What's yours thought is the s4 better than s4active. Maybe the note 2. I've used these both for a week not sure from a mixing modding point of view. Any input is great. This has been asked before I'm sure. What's the bests phones out for android.?? If you could upgrade for 0.00 what would you do and why? Thanks

$ø|\/|£ťhïñğ ¢ű$ț¤|\/| ⁴.².²