IDE 1.0.5 does not allow users to update libraries from developers

[drmpf]

Once a library is installed the IDE V1.0.5 does not allow it to be installed again.
Request removing this check

It has been suggested a dialog be opened to alert user the library exists, but I am not sure what this achieves. With no concept of library version nos what is the user expected to do other then alway say overwrite.

Also If touching this function, request that the link between zip name and library name be overridable.

For example if the zip has just a top level directory (or directories) then these should be installed as the libraries. This allows the zip name to include a version number so users can tell which version of the library they are installing.

It also allows multiple libraries to be installed from one zip file.
.eg.
pfodParserLib_V2.zip
contains just
-> pfodParser (dir)
then install pfodParser (dir) under libraries dir

pfodParserLib_V2.zip
contains just
-> pfodParser (dir)
-> pfodCmdParser (dir)
then install pfodParser (dir) and pfodCmdParser (dir) under libraries dir.
i.e. installs two libraries.

For backward compatability, if the top level of the zip file has any non-directory entries then use existing install process which uses the name of the zip as the library name.

[amcewen]

In a similar way to the version number, would it be possible to allow (but strip off) anything after a '-' in the library name?

That would allow library developers to easily package up releases from Github. For example, if you look at https://github.com/amcewen/HttpClient/releases/tag/v2.1 the "Source code (zip)" is created by Github when I create the release, but includes a directory named HttpClient-2.1, so I have to manually add the HttpClient.zip which is the same code but with the "-2.1" removed from the library name so it will install.

It would also allow users to use the "Download ZIP" button on the Github repo's main page. Github names the directory in the zip "-" (so in my HttpClient as an example it would be "HttpClient-master".

[matthijskooijman]

Why do you need the part after the - removed exactly? AFAIU, the Arduino IDE doesn't care how the library directory is called, it just looks at the .h files inside to see which library to use (e.g., if you #include <Foo.h> and a file libraries/Foo-1.2/Foo.h is available, then it should happily include the Foo-1.2 library in the build). Then it actually makes sense to keep the part after the -, so you can later still see which version you installed?

[amcewen]

Having the library version available in the name sounds like a good idea but I think would cause more problems. Which version of Foo.h should the build system include once I've got the Foo-1.2, Foo-1.3 and Foo-3.5 libraries installed? :-)

Sadly dependency management isn't a trivial problem to solve... :-(

[matthijskooijman]

My guess it is will currently just choose the first available version, but I agree that that could be confusing. However, in the recent library format discussion, I suggested to allow the user to choose in case multiple versions are available, which would probably solve this problem (and if that is implemented, implementing the "strip everything after the -" feature now doesn't make sense IMHO).

[pfeerick]

@matthijskooijman The issue with '-' in the filename is because library names (according to the Arduino IDE) are only permitted to have letters and numers - no spaces, and can't start with a number). So the 'add library' function will fail to install the library. If you manually create a library with a hyphen or dash in the name, you'll get the same error when you start the IDE, and the library will be ignored. So at minimum, hyphens/dashes need to be replaced with underscores. And if it is a github repo zip, it makes sense that -master be removed automatically also. However, as you say, it's the name of the .h file that is important for matching, so 'elapsedMills.h' in a elapsedMillis_v1 folder is perfectly valid. However, that leads to the sticky issue of different named folders with the same name .h files in, which the IDE also accepts. 👻 in the IDE, anyone?

Tested on win-Arduino v1.0.5.

[matthijskooijman]

@pfeerick, good point, I didn't consider that. Perhaps allowing dashes in library names makes sense, then?

[pfeerick]

Agreed. Does anyone know why that restriction was put in place?

[cmaglie]

@drmpf the dialog is meant to ask confirm before overwriting an existing library. You may be an expert and know what you are doing, someone else may not and overwriting something without asking may be unexpected.

@pfeerick
Until now the IDE refused names with "-", changing this behaviour to "accept it but strip the name after the -" seems weird and very github-specific (what about other SCM sites? bitbucket? gitorius? another?).
We could change the rule, and simply accept "-" in the name, but this lead (in the github case) to users installing multiple instance of the same library without warnings, and this may lead to even more confusing situations.

[pfeerick]

@cmaglie On windows, there is no dialog (box?) - the space where the compile/upload progress bar normally is turns orange, and the text there says 'a library named xyz already exists' . There are no options, no more information, nothing. Is that the behaviour you're thinking of when you say dialog? As I commented on the mailing list I would have expected a proper prompt (windows ' are you sure you want to?'' style).

btw, bitbucket is even worse for zips - it wacks a '-' and a commit id on the end of the zip name and the zips root folder.

[cmaglie]

@pfeerick
we are talking about a new feature: IDE to allow updating i.e. overwriting, an already installed library. The dialog that I'm talking about is not implemented yet and in my mind is something like what you suggested: "are you sure you want to overwrite XYZ? [Yes] [No]".

C

[drmpf]

Cristian,
My idea was that there would only be one version of the library in the
library path at one time.
The zip file name+version is for developers to keep track of what
version of the library the zip file contains and for the users to
quickly identify if they are accessing the correct zip file.

Once the user has chosen to load that library, I think prompting them
about overwriting is unnecessary.

What is the user expected to do?
If they loading an updated library, then that is what they want to do.
Don't anoy the user, just do what they asked.

If they are reloading an old library (by mistake instead on choosing the
new library zip) then they are expecting to override and existing
library and this dialog does tell them anything new and more importantly
it does not alert them to that problem, since the dialog cannot tell
what the existing installed version is, so no use displaying it.

If they are just reloading an existing library, for the fun of it or by
mistake, then there is no danger, again no use displaying a dialog box.

So my vote is not to display the dialog prompting the use yes or no,
there are too many on those dialogs already in computing and this one
does not add anything useful.

matthew

On 28/11/2013 9:38 PM, Cristian Maglie wrote:

@drmpf the dialog is meant to ask confirm before overwriting an existing library. You may be an expert and know what you are doing, someone else may not and overwriting something without asking may be unexpected.

@pfeerick
Until now the IDE refused names with "-", changing this behaviour to "accept it but strip the name after the -" seems weird and very github-specific (what about other SCM sites? bitbucket? gitorius? another?).
We could change the rule, and simply accept "-" in the name, but this lead (in the github case) to users installing multiple instance of the same library without warnings, and this may lead to even more confusing situations.

---

Reply to this email directly or view it on GitHub:
#1704 (comment)

[Lauszus]

Maybe it it would be a good idea to support periods '.' in directories as well?

[drmpf]

On 28/11/2013 9:38 PM, Cristian Maglie wrote:

@drmpf the dialog is meant to ask confirm before overwriting an existing library. You may be an expert and know what you are doing, someone else may not and overwriting something without asking may be unexpected.

Cristian,
My idea was that there would only be one version of the library in the library path at one time.
The zip file name+version is for developers to keep track of what version of the library the zip file contains and for the users to quickly identify if they are accessing the correct zip file.

Once the user has chosen to load that library, I think prompting them about overwriting is unnecessary.

What is the user expected to do?
If they loading an updated library, then that is what they want to do. Don't annoy the user, just do what they asked.

If they are reloading an old library (by mistake instead on choosing the new library zip) then they are expecting to override an existing library and this dialog does tell them anything new and more importantly it does not alert them to that problem, since the dialog cannot tell what the existing installed version is, so no use displaying the dialog at all.

If they are just reloading an existing library, for the fun of it or by mistake, then there is no danger, again no use displaying a dialog box.

So my vote is not to display the dialog prompting the use yes or no, there are too many on those dialogs already in computing and this one does not add anything useful.

matthew

[matthijskooijman]

I quite disagree: Overwriting a library without prompting a user is bad form if you ask me. Often the user will know what he's doing and intend to overwrite the library, but there will be cases where a user didn't realize they already have the library installed, where he doesn't realize that two seemingly different libraries (for different architectures perhaps) are really the same library, or where he mis-clicks and selects the wrong file.

Offering a choice in a dialog is the proper way to fix this, IMHO.

[pfeerick]

As an advanced user, perhaps not having a warning is plausible. However, I
have yet to see any software just overwrite a pre-existing file or folder
without some form of warning. I know I would curse the soul of any
software developer who did that... After all, why should a new library
overwrite one I have that I may have customised without warning? Anyway,
when the library meta data special and manager are realised, it should be
able to identify and handle upgrade and same-named-but-different libraries
using said meta data.
On 29/11/2013 8:32 pm, "Matthijs Kooijman" [email protected] wrote:

I quite disagree: Overwriting a library without prompting a user is bad
form if you ask me. Often the user will know what he's doing and intend to
overwrite the library, but there will be cases where a user didn't realize
they already have the library installed, where he doesn't realize that two
seemingly different libraries (for different architectures perhaps) are
really the same library, or where he mis-clicks and selects the wrong file.

Offering a choice in a dialog is the proper way to fix this, IMHO.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1704#issuecomment-29507940
.

[drmpf]

A warning is fine just show in red at the bottom of the screen that the existing library has been overridden.
but do not interrupt the user and force them to click another button to dismiss this warning
see "Why you should not use Dialog boxes to Interrupt the User"
http://www.forward.com.au/javaProgramming/javaGuiTips/dialogBoxes.html

If you are an advanced user who customizes your libraries, make a copy. Novice uses will not be doing this.
As I mentioned above, if the user already has the library install then not a problem, override same with same
If he mis-clicks, the library won't show up in his ide.
By all means give the user a message at the bottom of the screen, but please do not add another y/n dialog box

[drmpf]

If you really want to help the user, forget y/n dialog boxes and rename any existing library folder _1, _2 etc so the user can easily undo any fat finger mistakes, or go back to the previous library if the 'updated' library turns out to have new and better bugs

[pfeerick]

So now you want the user informed that the IDE has overwritten and
destroyed any pre-existing library with the same name (how sarcastic can
you be) ? And to make the situation unmanageable , we'll just have the old
one renamed to_1,_2, etc., which could result in them being selected by
the compiler for inclusion still, instead of the newly installed library?
(can someone more experienced comment on this... Will the compiler/tool
chain sort like lib, lib_1,lib_2, resulting in likelihood of lib being
used?)

As a beginner user, I would have been hesitant to overwrite something when
trying out a new library (esp. since I don't know much about this library
stuff).

As an intermediate user (in no way do I consider myself advanced) , I
manually unpack and copy new library's due to inconsistent package, and to
prevent loss of MY work.

I presume advanced users just will it to install? :-P

I understand and support the intent of your discussion on prompts in
software apps, but that would require a major overhaul of the IDE interface
effectively implement (plus differentiate even more from its roots in
Processing) , and since we're used to dialogue boxes protecting us from
stupid decisions, a dialogue box will probably be it. Maybe it should have
three choices? [OVERWRITE] [BACKUP EXISTING] [CANCEL]

This is really a minor detail in the grand scheme of the Arduino IDE, and
will most likely be better resolved when the library manager is
realised. Then all the nice subtle status bar messages and progress
updates can be used.
On 30/11/2013 8:12 AM, "drmpf" [email protected] wrote:

If you really want to help the user, forget y/n dialog boxes and rename
any existing library folder _1, _2 etc so the user can easily undo any fat
finger mistakes, or go back to the previous library if the 'updated'
library turns out to have new and better bugs

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1704#issuecomment-29539498
.

[plocher]

@matthijskooijman wrote

the Arduino IDE doesn't care how the library directory is called, it just looks at the .h files inside to see which library to use

@drmpf wrote:

there would only be one version of the library in the library path at one time

This is the elephant in the room. The filesystem expresses library uniqueness in its directory name while the IDE expects uniqueness in the header file name. The IDE is being both "too smart" and "too stupid" at the same time - it attempts to figure out what the user wants, but can't actually deliver that mind reading in any but the most trivial case.

Is it no wonder that confusion reigns? IMO, the a sane short term way to proceed in the inevitable conflict situation is for the IDE to fail the compile (with a list of all the conflicting libs found) if it EVER finds multiple libraries that match the .h file name it is looking for.

Of course, in the best socratic tradition, you need to ask "OK, then how does the user fix that error"?

Right now, they can't, because

• there is no way for two library developers who happen to choose foo.h as their include file name to peacefully coexist - a disincentive for developers trying to work in the same area (LCD support, anyone?).
• there is no support for multiple versions of the same lib to peacefully coexist - a disincentive for users to experiment and explore
• The sketch design pattern doesn't provide a way for the user to say "hey, wait - I can help here because I know something that the IDE doesn't..."

Address this fundamental disconnect and the question of conflicting libraries will get easier to manage.
Ignore it, and it will be practically impossible for a future library manager to solve the problem.

Again, IMO, one solution might be for the user to specify which FILESYSTEM instance of a library they prefer. A better solution (again, IM(ns?)HO) might be to re-examine the mindset that presumes that "dumbing down the language" in this way actually simplifies the user's experience...

-John

[ffissore]

While I can't redesign nor change the mindset that brought us here, a couple of things happened in the meanwhile.

@PaulStoffregen coded #2850 which notified users about a possible conflict. He also added smarter choice of the library (which basically says: if 2 libs have foo.h and one lib is called "foo", then pick foo.h from "foo")

We added lib manager, which allows you to quickly switch between library versions.

I think we can close this as "partially fixed"