pyfa-org / Pyfa

Python fitting assistant, cross-platform fitting tool for EVE Online
GNU General Public License v3.0
1.61k stars 408 forks source link

Error occurs on "Export Fitting" #1900

Closed ryandemopoulos closed 5 years ago

ryandemopoulos commented 5 years ago

Bug Report

Installed v2.8.0, upgraded from v2.7.0. If I create a fitting for any ship and attempt to export that fitting using the "Export Fitting" button from the File menu, I get an error.

Expected behavior:

When I click the "Export Fitting" button, and indicate an XML file name to save to, it exports the file.

Actual behavior:

File is not exported, and I receive the following PYFA error:

pyfa v2.8.0 EVE Data Version: 1459933 (2019-02-16 02:18:51)

OS version: Windows-10-10.0.17134-SP0 Python version: 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 23 2018, 23:31:17) [MSC v.1916 32 bit (Intel)] wxPython version: 4.0.4 (wxWidgets 3.0.5) SQLAlchemy version: 1.0.5 Logbook version: 1.4.3 Requests version: 2.21.0 Dateutil version: 2.8.0

####################

Traceback (most recent call last): File "C:\projects\pyfa\gui\mainFrame.py", line 421, in showExportDialog File "C:\projects\pyfa\service\port\port.py", line 288, in exportXml File "C:\projects\pyfa\service\port\xml.py", line 329, in exportXml TypeError: 'Fit' object is not callable

Release or development git branch? Please note the release version or commit hash:

Release version 2.8.0

Operating system and version (eg: Windows 10, OS X 10.9, OS X 10.11, Ubuntu 16.10):

Windows 10

Other relevant information:

Strangely, when I tried to install v2.7.0 and go back to a known working copy of PYFA, that version no longer works either. Has me wondering if there is some kind of lingering issue, such as in the registry for example.

All this was working before I did the upgrade to 2.8.0.

blitzmann commented 5 years ago

Im curious, as @DarkFenX and I were just recently talking about this export wondering how useful it actually is, what do you use the xml export for?

ryandemopoulos commented 5 years ago

I save fits to my hard drive, to pull them up later. New to the game, so I have like no skills and saving the fits allows me to quickly pull up fits and see what skills I should train next.

For example, I can't fly interceptors yet. So I built an interceptor, saved it, and when i'm done training Cybernetics I'll come back to the fit and instantly be able to see what skills I'm missing for it.

That type of thing.

DarkFenX commented 5 years ago

Fixed in 37ad2faa8e79a13dd415554661546872e615e828

DarkFenX commented 5 years ago

@ryandemopoulos why you do not just keep those in pyfa database? Do you want to keep it clean or something?

I guess file format is irrelevant for this use-case?

ryandemopoulos commented 5 years ago

I'm not sure what you mean; I'm not sure what "pyfa database" is. I open the app, pick a ship, fit it, and save the fitting to my local disk. I'm not a pyfa expert, so unsure what the pyfa database is--my apologies. I'm pretty new at all this.

DarkFenX commented 5 years ago

If you fit a ship, pyfa saves this fitting for you. It is stored in <user folder>\.pyfa\saveddata.db, if you are using windows. Next time you open pyfa you will still have that fitting in the program itself.

Hence I am interested, why do you have to export to XML file.

We were about to remove that functionality in this release but @blitzmann convinced me to keep it for now. So any information on how it's used is very valuable.

Forgot to mention that old version does not work because saveddata.db schema was changed to support new price-related features.

blitzmann commented 5 years ago

@ryandemopoulos Still curious as to what you do with the export files 😄 Do you export them to load them on another device (from computer to laptop, maybe)? There's better ways to do that in that case. Otherwise, the fits should automatically be saved for that installation of pyfa.

We're just trying to get better feedback from users how they use this functionality, since XML export is on the chopping block as the use cases that we (@DarkFenX and I) can think of are quite limited

FYI, in case you need this functionality, a dev build can be found here that contains the fix from @DarkFenX:

https://ci.appveyor.com/project/blitzmann/pyfa/builds/23327691/artifacts

ryandemopoulos commented 5 years ago

I use the XML exporter to save fits to a OneDrive folder on my machine. This allows me to share fits between two instances of PYFA on two different machines. For example, I can make a fit at home, save it to my OneDrive (which is just a local folder on my machine that sync up to the cloud), and then I can go to work and load up that fit and continue to where I left off. If there was an easy way to "share the pyfa database" between machines then maybe I couldn't need this--but since you're asking how I use it, that's what I do to share between machines. It just saves me from having to re-make the fit on every machine I play EVE on, really.

I know I'm only one person, and I don't have to pay the price of upkeep of this functionality, but FWIW I hope you don't remove the feature--since it's the main way I do things on PYFA. :) Also, if I pave over a machine (which happens regularly at work), then I would lose the database, correct? So I like the idea of being able to persist my fits regardless of machine and whether I format it.

DarkFenX commented 5 years ago

@ryandemopoulos , there's better way to do it, and i use it myself - just put saveddata.db to the cloud and make links to it on all machines where you intend to use pyfa (google will tell you how to make links). I am using such approach myself and it's probably way more convenient than what you're doing.

blitzmann commented 5 years ago

https://github.com/pyfa-org/Pyfa/wiki/Cross-Platform-Data-Sharing

I will warn though that this does make it easier to open two instances at once, which is unsupported and can lead to weird shit (ex, both laptop and desktop have pyfa open utilizing the same database). but for the most part, this works well and I've used it in the past :)

The problem with XML export is that it's a lossy format. You lose pretty much everything that isn't the fittings (character, projections, commands, implants, maybe module state (it's been a while since I've looked), etc).

ryandemopoulos commented 5 years ago

I definitely open two instances at once--it's actually how I pretty much always operate so sharing the DB file won't work for me if I can't have two instances open at the same time. (I likely would only be using one instance at a time, but I would have them both open at the same time for sure)

The XML format may be lossy, but I haven't lost anything I care about yet--maybe I'm just not skilled enough in-game to have encountered a problem here. (I don't really do much with expensive implants yet; I'm space poor :))

Side note: I think I might have figured out how this database stuff worked on my own, if you had put the Preferences (CTRL+P) menu item in the File menu, rather than Window. That might be something you guys should consider doing from a discoverability perspective.

Until you support multi-instancing, I think I'd still use the XML export feature to share. It works well, easy to manage, and as a bonus if my database becomes corrupted somehow then i don't lose all my fits in a single cataclysm. :)

blitzmann commented 5 years ago

I definitely open two instances at once--it's actually how I pretty much always operate so sharing the DB file won't work for me if I can't have two instances open at the same time.

I'm not saying it won't work. I've definitely done it before without issues. I'm just saying that it's a bit more prone to be buggy - one instance might not know about changes from another instance. Although now that I think about it, most things that happen within the application are committed immediately and should therefore show up in either. But there's bound to be some edge cases, and you just have to be aware that it's something that we don't support (not for lack of wanting to support it - sqlite database are inherently single-user).

I would definitely try this method and see if it works for you.

DarkFenX commented 5 years ago

Wrong, committed changes do not appear in sqlalchemy session of another magically. If some object was loaded and was changed in DB externally - i think SQAlchemy will not get any updates to it. It can easily cause various issues, maybe even up to DB corruption.

When i come from home to work, if I had pyfa open - i always close it because it starts spamming consistency errors.

blitzmann commented 5 years ago

Ah your right... for some reason I thought the session would periodically check record in database and load, but that doesnt make any sense now that I think about it lol. So yeah, having 2+ sessions open on same database isn't going to work.

Still trying to see the use case for that tho. Why would you use two pyfas at same time? When done with one, close it, maybe wait for google drive/one drive to sync file, then open on other machine

DarkFenX commented 5 years ago

Pyfa doesn't commit anything when you close it iirc, it commits after actions. So you do not need to wait after closing, if your last action was a while ago.

ryandemopoulos commented 5 years ago

Still trying to see the use case for that tho. Why would you use two pyfas at same time? When done with one, close it, maybe wait for google drive/one drive to sync file, then open on other machine

If you're like me and you switch between work and home machines for playing EVE, it's not that uncommon to have pyfa open on two machines. Sure, remembering to close one before you use the other is an easy solution--but how often will I remember to do that? I got 99 problems... :)

ryandemopoulos commented 5 years ago

By the way, pyfa is amazing and I'm just getting into eve and I have as much fun in pyfa as I do in the actual game. :) These are first world problems here. Just letting you guys know how I use it and that the XML exporter has been great for me. Who knows if I'm the only person out there who does this, lol.

r00tcmdr commented 5 years ago

@blitzmann If you're still looking for why a small subset of people really, really need the XML Export still... The EVE client still cannot accept any sort of copy-based import (or copying fits from in-game links) and keep Mobile Depots in cargo. I stock pre-made doctrine fits and it's much easier to keep a master fit in pyfa and import from the XML files to update the in-game fits for multibuy/multifit. It's also a nice backup for when ccp breaks other items in fit copies (a few weeks ago there were issues with where the copy would place drones making invalid fits unless you used the XML import).