apertium/apertium-python

Appveyor Apertium installation

Closed this issue · 22 comments

sushain97 commented

maybe through setup.py install? - Linux could piggyback off that too

orgh0 commented

@sushain97 some idea on how I should proceed with this?
Also, for testing and implementation, a VM for windows should work?

sushain97 commented

VM for windows should work

Yea.

some idea on how I should proceed with this?

I'm afraid not. Some googling is probably the best course of action. There are some links I've sent that are also related.

orgh0 commented
orgh0 commented

Can you somehow give me permissions to start/stop/retry builds on Appveyor? It would allow me to test faster. @sushain97

orgh0 commented

@sushain97 I've been able to make lt-proc and other similar commands work on the windows command prompt.

But I encounter this error when I try to run the library

C:\Users\DELL\Documents\arghya_work\apertium-python-master\apertium-python-master>python
Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import apertium
>>> a = apertium.Analyzer('en')
>>> a.analyze('cats')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\DELL\Documents\arghya_work\apertium-python-master\apertium-python-master\apertium\analysis\__init__.py", line 37, in analyze
    result = execute(in_text, commands)
  File "C:\Users\DELL\Documents\arghya_work\apertium-python-master\apertium-python-master\apertium\utils.py", line 27, in execute
    subprocess.Popen(command, stdin=subprocess.PIPE, stdout=subprocess.PIPE),
  File "C:\Users\DELL\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 709, in _init_
    restore_signals, start_new_session)
  File "C:\Users\DELL\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 997, in _execute_child
    startupinfo)
FileNotFoundError: [WinError 2] The system cannot find the file specified
>>>

I'm working on this.
Do you by any chance have a hint of what might be going wrong?
subprocess module does exist

sushain97 commented
orgh0 commented

@sushain97


In [3]:  g = apertium.Generator('en')

In [4]: g.generate('^cat<n><pl>$')
Error: Cannot not open file '/usr/share/apertium/apertium-eng/eng.autogen.bin'.

Out[4]: ''

In [5]:

In [5]: g.generator_cmds
Out[5]:
{'eng': [['lt-proc',
   '-z',
   '-g',
   '/usr/share/apertium/apertium-eng/eng.autogen.bin']]}

eng-gener.mode has this path given by default.
Ideas on how I should go about this?

orgh0 commented

@sushain97


In [1]: import apertium

In [2]:  g = apertium.Generator('en')

In [3]: g.generate('^cat<n><pl>$')
Out[3]: 'cats'

This are working finally. But the workaround seems really hacky. Theres a need to change the path in every .mode file.

Suggestions on how we can wrap the whole process and make it easier for people to use it?

sushain97 commented

You can modify things that look like paths when you read mode files. How did you install the package? I would expect a proper Windows installation to also set the .bin path correctly.

orgh0 commented

@sushain97

STEPS FOLLOWED:

  1. Path for the apertium-python set to apertium-all-dev/share/apertium
  2. Download apertium-all-dev.zip
  3. Extract and set it's apertium-all-dev/bin folder to the PATH
  4. Download .deb language data
  5. Extract using 7z
  6. Copy the contents to of language data to apertium-all-dev/share/apertium
  7. All .mode files need to be updated as their paths have /usr/share assumed

IDEA:
I was thinking if usr could be made a variable and replaced with apertium-all-dev/share ?

sushain97 commented

Right, the .deb files are built in a particular way with that prefix.

All .mode files need to be updated as their paths have /usr/share assumed

We can't ask people to do this, unfortunately. That would make the install process unduly burdensome and confusing. It needs to be done automatically as a part of the extraction step or at time of lt-proc calls.

Also, we shouldn't make any assumptions about where the binaries are located, they should just be assumed to be on the path. Therefore, a Windows installation of this package should ensure they end up somewhere in the path or that we modify the system path to include it. I'm not sure what the standard is for Windows Python installs.

orgh0 commented

@sushain97
I'm writing a windows script that will download apertium-all-dev in the same repo and add it's bin to the PATH.

But there's a problem here as well.
There's something called the 7z which extracts .deb files in windows.
Now I don't know how I'm gonna install it from the script. Because I don't see a method for windows installation without a GUI.

thoughts?
Also, at this point what would be the best way to go about the method figured out to make things work on windows?

sushain97 commented

apertium-all-dev in the same repo

A real user wouldn't have a repo on their disk, they would have an installed package through pip (or maybe Debian but that we can deal with later).

7z which extracts .deb files in windows

There are definitely ways to extract the file using Python. Googling something like 'extract deb Python` might be useful. Maybe Tino also packages them as a plain tar.gz or something?

Also, at this point what would be the best way to go about the method figured out to make things work on windows?

I'm not sure what you're asking.

orgh0 commented
sushain97 commented

Right now, the idea is if a user(like the one who reported an issue on
GitHub) clones the repo and tries to run Apertium+Python.They should be
able to.

That isn't a Windows installation though. The goal is to have this be pip-installable.

And also get the appveyor test to pass.

Yes. As I said, this should be done via setup.py install.

sridharbodla commented

while i am trying with python jupyter notebook getting the below error.

image

orgh0 commented

@sushain97

How do you propose I should go about the .mode file modifications of the paths?

orgh0 commented

@sridharbodla This isn't ready for windows installation yet. Once this issue is closed you can try to run it and we'll figure out the problems you're having :)

sushain97 commented

How do you propose I should go about the .mode file modifications of the paths?

Detect things that look like paths and map them to corresponding file on the Windows filesystem based on where the mode file is located. You'll have to be a little intelligent about it.

orgh0 commented

@sushain97

In [1]: import apertium

In [2]: a = apertium.Analyzer("en")

In [3]: a.analyze("cats")
'apertium' is not recognized as an internal or external command,
operable program or batch file.
Out[3]: []

In [4]: g = apertium.Generator('en')

In [5]: g.generator_cmds
Out[5]: {}

In [6]: g.generate('^cat<n><pl>$')
Out[6]: 'cats'

In [7]: t = apertium.Translator("en", "es")

In [8]: t.translate("cats")
Out[8]: 'Gatos'

For analysis, I tried the lt-proc command directly but that has some postprocessing issues that I couldn't figure out.
I've created an issue for it.

  • 👍1
  • 🎉1
orgh0 commented

@sridharbodla could you try cloning the windows branch and run Apertium+Python with the instructions in readme?

sounak98 commented

I ran the code from the windows branch following the GitHub Gist link that @arghyatiger had provided in the README and the tests pass but however I have a few suggestions.

  • If I want to install a language package other than the 2 that are not pre-installed, I'd have to change lines in the code, it would be great if you could take the packages as arguments or write a code that would install language packages.
  • The automated windows script does pretty much all of the work however I believe that the 7z dependencies should be removed before a setup.py is written.
  • The windows.py is a good test script for apertium-python, this could be changed into a setup.py file, thus making people's lives.

Once this is done, this could be a great software for running apertium-python on windows as I myself have tried doing so for my college previously and have faced a lot of issues.