@m_m, I believe I’ve done everything correctly, but who knows, perhaps I can’t see the forest for the trees, as they say. I may just be missing some specific detail that’s not obvious (to me).
My goal is to move dozens of projects from my Particle Dev environment over to Workbench. The basic issue is that when I think I’ve done everything correctly and closed the workspace, the source file is returned to the initial boilerplate when I reopen it.
I did a screen recording, but it’s 11 MB and I’m not sure how to best get it to you. Please feel free to PM me if you have a preferred way to get that file.
So…perhaps this is my issues. I had “assumed” that I should first create a new project in a new directory, keeping the new Workbench files separate from the old Particle Dev files. However, it seems all I needed to do was to run Particle: Import Project and that would transform my existing (Dev) project folder into the state required for Workbench. Is that correct? If so, the transition from using Particle Dev to using Workbench on a project would be very simple. However, since the import creates and populates the lib folder, if I want to compile with Dev for some reason (such as having coding issues raised by Workbench), I need to temporarily rename that folder.
That's the way how it's intended, yes. It should be as simple as possible
Could you elaborate?
When you do in Dev you will also get the lib folder populated. So that in and of itself doesn't explain the need for the renaming.
One thing I could imagine is that you are importing a project that features dependencies in project.properties and when migrating that project to Workbench it will by default set your project up for local compiling, which in turn requires the libraries to be copied to your lib folder as the dependencies may not be resolvable when offline.
If this is the case for you, then this would require some update in Desktop IDE to set some precedence of dependency over local lib or vice versa. But any update for Desktop IDE is highly unlikely.
Alternatively - probably more likely - Workbench could get a switch for project import/migration to either force offline compilability or keep it dependent on the cloud lib repo.
The former would need to disable/comment the dependencies that may be present in project.properties - @m_m, what do you think?
BTW, how does Workbench treat libraries that in turn also have dependencies? Are they copied to the project recursively?
After I had the epiphany early this morning about “importing a project” is really just modifying the project folder to be Workbench ready, I went back and tried to compile under Dev to see what would happen. I ended up getting errors due to multiple declarations associated with the included libraries. I decided to simply rename the lib folder to libx and all was good.
For what it’s worth, I’d call the import project task something else, such as Particle: Prep Dev project for Workbench. To me, that’s more intuitive. The existing task would likely have to stay for folks who already are using it.
Yes, there are dependencies listed in project.properties, which I thought was required by Dev in order to be able to get to those libraries. I’ve always done that (or Dev did it for me). However, the library files were (typically?) not there. I apologize for being vague, but I guess I didn’t really pay attention to these details since Dev simply just worked for me.
Not sure about libraries with dependencies, but I’m assuming they don’t come in, as I’m sure the libraries I’m using list dependencies and I don’t see any other than the ones I explicitly reference in project.properties.
@ScruffR, thanks, again for your amazingly quick response. I have dozens of devices in the field and have only been successful with Particle due to this forum and folks like you offering timely assistance.
That would ignore the fact that CLI projects (which actually were there before Dev) should be migrated the same way.
There are plenty other possible names for the same thing (e.g. Particle: Migrate project, Particle: Create Workspace from project, ...) one might find more intuitive but others won't
What the process actually does is creating a xxx-workspace file, add some other "housekeeping stuff", potentially download/install the toolchain and dereference online dependencies in order to become cloud independent.
If you can come up with a name for that which everybody will agree with, Mirande may be persuaded that way
My question was rather targeted at Mirande as he probably knows what I meant and he has to find a solution for all use-cases (of which my proposed challenge may be an edge case that requires extra thought - if it's not already solved ).
Point well made…one person’s obvious is another’s obscure.
With that said, I’ll offer a final possibility: Particle: Prep project for Workspace. That may be generic enough and avoid the “import” term that befuddled me.
BTW, how does Workbench treat libraries that in turn also have dependencies? Are they copied to the project recursively?
yes, they are. for exampe, if you have dependencies.InternetButton=0.1.14 in your project.properties, you'll see that neopixel@0.0.14 and particle_ADXL362@0.0.1 are installed into your ./lib directory after importing.
I ended up getting errors due to multiple declarations associated with the included libraries.
to be clear, supporting both Dev and Workbench within the same project isn't really our goal. the intent of the Import command is to give you a reasonably easy path to bringing your existing projects into Workbench.
likewise, while we've discussed the notion of having "cloud" and "local" projects, our focus today is on building support for local compilation - which requires deps to be installed locally - with the understanding that "cloud" should always just work(tm) and be well-supported by our Web IDE. Ultimately, Workbench is targeted at users who have outgrown our Web IDE,
if you have a project that after importing into workbench cannot be compiled using the cloud but compiles fine using the local compilation tasks, i'd love to take a look. if you can, host a .zip file (or .tar.gz) on a service like dropbox and PM me a link to it.
@m_m, I'd expect CLI would barf just the same and if I'm not mistaken CLI should still be able to compile the same projects, or not?
The simplest way to achive that (and as positive "side-effect" also stay compatible with Dev) would be - as previously mentioned - when the import process did ...
... since they are not required anymore (or rather go in the way) after the libraries have been copied to the project.
in Dev you will also get the 
).