www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why did etc.c.odbc move to core.sys.windows?

reply singingbush <singingbush hotmail.com> writes:
The phobos documentation states that the odbc modules:

etc.c.odbc.sql
etc.c.odbc.sqlext
etc.c.odbc.sqltypes
etc.c.odbc.sqlucode

will be removed in Feb 2022 and I should instead use 
`core.sys.windows` but ODBC isn't a Windows only thing so this 
seems a bit odd.

Changing the module locations wouldn't be so bad if changing my 
imports didn't also break my code.

Also all the modules in core.sys.windows have `version (Windows)` 
in them, including `src/core/sys/windows/odbcinst.d`:

https://github.com/dlang/druntime/commit/136ff8cd0c8ec300e9e1d177a94b336cf526d9ff#diff-b96154f02e79b2aab93b614dce927ff24deac3cfea629fb456bf8a95526bcbb8

which again isn't ideal seeing as I want to use odbc from Linux.

Can someone please rethink this planned removal of `etc.c.odbc.*`
May 22
next sibling parent singingbush <singingbush hotmail.com> writes:
Also, the commit that marked `etc.c.odbc.*` as scheduled for 
removal also deleted a ton of code and changed behaviour at the 
same time. Typically a deprecation is supposed to be done a good 
few releases before making breaking changes.

It was this commit in phobos that caused problems:

https://github.com/dlang/phobos/commit/88fd21e7368e8e2158a6ac75d43587c77886d6dd
May 22
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 23 May 2021 at 01:22:19 UTC, singingbush wrote:
 The phobos documentation states that the odbc modules:

 etc.c.odbc.sql
 etc.c.odbc.sqlext
 etc.c.odbc.sqltypes
 etc.c.odbc.sqlucode

 will be removed in Feb 2022 and I should instead use 
 `core.sys.windows` but ODBC isn't a Windows only thing so this 
 seems a bit odd.
I'm guessing it's because Windows is the only OS that ships these header files as part of the base installation. On Linux, they're provided by a third-party package (e.g. on Debian it's `libodbc`).
May 22
parent reply singingbush <singingbush hotmail.com> writes:
On Sunday, 23 May 2021 at 03:31:27 UTC, Paul Backus wrote:
 On Sunday, 23 May 2021 at 01:22:19 UTC, singingbush wrote:
 The phobos documentation states that the odbc modules:

 etc.c.odbc.sql
 etc.c.odbc.sqlext
 etc.c.odbc.sqltypes
 etc.c.odbc.sqlucode

 will be removed in Feb 2022 and I should instead use 
 `core.sys.windows` but ODBC isn't a Windows only thing so this 
 seems a bit odd.
I'm guessing it's because Windows is the only OS that ships these header files as part of the base installation. On Linux, they're provided by a third-party package (e.g. on Debian it's `libodbc`).
For me that doesn't indicate that it should be in `core.sys.windows`, it indicates that either: A: The installers for other platforms need to ensure appropriate dependencies are installed B: odbc has no business being in core D language and should just be something that needs building independently, probably as a dub package.
May 26
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 26 May 2021 at 10:35:16 UTC, singingbush wrote:
 On Sunday, 23 May 2021 at 03:31:27 UTC, Paul Backus wrote:
 On Sunday, 23 May 2021 at 01:22:19 UTC, singingbush wrote:
 The phobos documentation states that the odbc modules:

 etc.c.odbc.sql
 etc.c.odbc.sqlext
 etc.c.odbc.sqltypes
 etc.c.odbc.sqlucode

 will be removed in Feb 2022 and I should instead use 
 `core.sys.windows` but ODBC isn't a Windows only thing so 
 this seems a bit odd.
I'm guessing it's because Windows is the only OS that ships these header files as part of the base installation. On Linux, they're provided by a third-party package (e.g. on Debian it's `libodbc`).
For me that doesn't indicate that it should be in `core.sys.windows`, it indicates that either: A: The installers for other platforms need to ensure appropriate dependencies are installed B: odbc has no business being in core D language and should just be something that needs building independently, probably as a dub package.
I'd say B. As far as I am aware, none of the currently active Phobos contributors is interested in ODBC, so it is a disservice to our users to claim that this functionality is supported. It should be moved to separate repo maintained by people who actually use it.
May 26
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 5/26/21 7:13 AM, Petar Kirov [ZombineDev] wrote:
 On Wednesday, 26 May 2021 at 10:35:16 UTC, singingbush wrote:
 On Sunday, 23 May 2021 at 03:31:27 UTC, Paul Backus wrote:
 On Sunday, 23 May 2021 at 01:22:19 UTC, singingbush wrote:
 The phobos documentation states that the odbc modules:

 etc.c.odbc.sql
 etc.c.odbc.sqlext
 etc.c.odbc.sqltypes
 etc.c.odbc.sqlucode

 will be removed in Feb 2022 and I should instead use 
 `core.sys.windows` but ODBC isn't a Windows only thing so this seems 
 a bit odd.
I'm guessing it's because Windows is the only OS that ships these header files as part of the base installation. On Linux, they're provided by a third-party package (e.g. on Debian it's `libodbc`).
For me that doesn't indicate that it should be in `core.sys.windows`, it indicates that either: A: The installers for other platforms need to ensure appropriate dependencies are installed B: odbc has no business being in core D language and should just be something that needs building independently, probably as a dub package.
I'd say B. As far as I am aware, none of the currently active Phobos contributors is interested in ODBC, so it is a disservice to our users to claim that this functionality is supported. It should be moved to separate repo maintained by people who actually use it.
I agree. A good path forward is for someone to create a replacement on dub, and then you can depend on that library. -Steve
May 26
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 26 May 2021 at 12:03:06 UTC, Steven Schveighoffer 
wrote:
 On 5/26/21 7:13 AM, Petar Kirov [ZombineDev] wrote:
 On Wednesday, 26 May 2021 at 10:35:16 UTC, singingbush wrote:
 [...]
I'd say B. As far as I am aware, none of the currently active Phobos contributors is interested in ODBC, so it is a disservice to our users to claim that this functionality is supported. It should be moved to separate repo maintained by people who actually use it.
I agree. A good path forward is for someone to create a replacement on dub, and then you can depend on that library. -Steve
Seems like the way forward.
May 26
prev sibling parent reply singingbush <singingbush hotmail.com> writes:
On Wednesday, 26 May 2021 at 12:03:06 UTC, Steven Schveighoffer 
wrote:
 I agree.

 A good path forward is for someone to create a replacement on 
 dub, and then you can depend on that library.

 -Steve
That's why I'm posting the problem [ddbc](https://github.com/buggins/ddbc/) does support odbc. It allows me to use MS SQL from a Linux system. It currently relies on `etc.c.odbc` and the proposed move to `core.sys.windows` completely breaks it. Rather than have odbc move from etc.c to core.sys.windows, I feel it should be dropped alltogther and be given a longer time frame for ddbc to do away with reliance on `etc.c.odbc`. Feb 2022 doesn't give a lot of time, a change like this should much more notice. It's things like this that stop people being able to use D in the workplace. The D introduces breaking changes far too often. It's completely unfair to put this demand on developers. I've got applications to work on, I don't want to have to spend so much time working around problems that have been created by the language itself.
May 28
parent reply Kyle Ingraham <kyle kyleingraham.com> writes:
On Friday, 28 May 2021 at 15:50:15 UTC, singingbush wrote:
 It's completely unfair to put this demand on developers.
If I’m not mistaken this doesn’t seem to be a deprecation since the code was moved from its original location. A deprecation would have left the code in place in possibly a maintenance-only mode and remove it next February after the warning period. I sympathize with your frustration here.
May 31
parent reply =?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> writes:
I see `etc.c.*` headers pretty useless in the standard library. The
phylosophy of most of the standard libraries are: provide what "every
programmer" might reasonably require when building a large collection
of software and provide relatively easy-to-code facilities.

Moving this to the runtime library is totally not a solution to this
problem, in my point of view. By definition, a runtime library
shouldn't have bindings to a random library that a few people uses.

The right direction would be to consider doing an external and optional
package for this type of bindings instead of forcing likely 90% of the
users to download bindings such as sqlite and odbc.

--=20
Sincerely,
Lu=C3=ADs Ferreira   lsferreira.net
May 31
next sibling parent reply Kagamin <spam here.lot> writes:
The original idea was to have an RDBMS support in phobos:
https://forum.dlang.org/post/ml76cf$c32$1 digitalmars.com
https://github.com/dlang/phobos/pull/3398
Jun 01
parent =?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> writes:
On Tue, 2021-06-01 at 08:19 +0000, Kagamin via Digitalmars-d wrote:
 The original idea was to have an RDBMS support in phobos:
 https://forum.dlang.org/post/ml76cf$c32$1 digitalmars.com
 https://github.com/dlang/phobos/pull/3398
Ooof. It is clear there was no proper discussion about it and that makes me really sad. I want to be clear that it is not about the importance of having ODBC wrappers in D ecosystem and rather choosing to have it on the standard library. I don't see why this should go into Phobos. A Dub package should=C2=A0be=C2=A0more than good enough, at least until that planne= d proposal for a standard high-level API materializes. Even then, a well-publicized Dub might be more appropriate, given all the issues we ran into with std.net.curl. Consider this to be just about the most formal veto I can extend. Agree, please do not add another c lib dependency to phobos. This should be a dub package. Those guys were literally ignored. The worst part of this attitude is that Walter didn't read the comments and enabled auto merge tag even if CyberShadow alerted him before merge. Staff should take care of its community instead of saying "because I want to". --=20 Sincerely, Lu=C3=ADs Ferreira lsferreira.net
Jun 01
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 31 May 2021 at 17:02:08 UTC, Luís Ferreira wrote:
 I see `etc.c.*` headers pretty useless in the standard library. 
 The phylosophy of most of the standard libraries are: provide 
 what "every programmer" might reasonably require when building 
 a large collection of software and provide relatively 
 easy-to-code facilities.

 Moving this to the runtime library is totally not a solution to 
 this problem, in my point of view. By definition, a runtime 
 library shouldn't have bindings to a random library that a few 
 people uses.
It wasn't moved to the runtime library, it needlessly existed in both places. One of them had to go.
Jun 05
parent reply =?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> writes:
On Sat, 2021-06-05 at 07:22 +0000, Iain Buclaw via Digitalmars-d wrote:
 On Monday, 31 May 2021 at 17:02:08 UTC, Lu=C3=ADs Ferreira wrote:
=20
 I see `etc.c.*` headers pretty useless in the standard library.=20
 The phylosophy of most of the standard libraries are: provide=20
 what "every programmer" might reasonably require when building=20
 a large collection of software and provide relatively=20
 easy-to-code facilities.
=20
 Moving this to the runtime library is totally not a solution to=20
 this problem, in my point of view. By definition, a runtime=20
 library shouldn't have bindings to a random library that a few=20
 people uses.
=20
=20 It wasn't moved to the runtime library, it needlessly existed in=20 both places.=C2=A0 One of them had to go.
Ok, sure, thats worse but moving forward is not deleting one of them, IMHO. AFAIK, libodbc is something external, even on windows, so why druntime is still dependent on such bindings? --=20 Sincerely, Lu=C3=ADs Ferreira lsferreira.net
Jun 05
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Saturday, 5 June 2021 at 17:39:34 UTC, Luís Ferreira wrote:
 On Sat, 2021-06-05 at 07:22 +0000, Iain Buclaw via 
 Digitalmars-d wrote:
 On Monday, 31 May 2021 at 17:02:08 UTC, Luís Ferreira wrote:
 [...]
It wasn't moved to the runtime library, it needlessly existed in both places.  One of them had to go.
Ok, sure, thats worse but moving forward is not deleting one of them, IMHO. AFAIK, libodbc is something external, even on windows, so why druntime is still dependent on such bindings?
Because it is is part of the mingw runtime, and the contributor to `core.sys.windows` translated all headers verbatim.
Jun 05
parent =?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> writes:
On Sat, 2021-06-05 at 21:14 +0000, Iain Buclaw via Digitalmars-d wrote:
 On Saturday, 5 June 2021 at 17:39:34 UTC, Lu=C3=ADs Ferreira wrote:
 On Sat, 2021-06-05 at 07:22 +0000, Iain Buclaw via=20
 Digitalmars-d wrote:
 On Monday, 31 May 2021 at 17:02:08 UTC, Lu=C3=ADs Ferreira wrote:
 [...]
=20 It wasn't moved to the runtime library, it needlessly existed=20 in both places.=C2=A0 One of them had to go.
=20 Ok, sure, thats worse but moving forward is not deleting one of=20 them, IMHO. AFAIK, libodbc is something external, even on=20 windows, so why druntime is still dependent on such bindings?
=20 Because it is is part of the mingw runtime, and the contributor=20 to `core.sys.windows` translated all headers verbatim.
Oh ok, it makes more sense now, although, I assume it was a mistake. To be honest, it should be more clear what bindings are valid on the druntime. Logically, bindings for the kernel headers and libc are accepted, but extensions like libodbc should be discussed previously and I think there's no specification for those type of additions. --=20 Sincerely, Lu=C3=ADs Ferreira lsferreira.net
Jun 05