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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021